On Thu, Feb 14, 2013 at 1:32 PM, John Carlson <yottz...@gmail.com> wrote:
> What I am suggesting is using full http with json is superior to rest. > For your session id based puts, how are you accumulating errors? Or are > you? > One can support bi-directional RESTful communications by indirection: one resource to receive the active command, one resource to observe for response. You PUT a value on the former resource, then GET from the latter to obtain feedback, status, or error information. The IDs might be easily computable from one another, and resources may even be associated with logical session IDs. You have made assertions about 'round trips' but none of them seem valid. With HTTP pipelining, a PUT on one resource and a GET on another (which might provide a response) can be delivered in one trip (potentially in the same packet), and their responses also delivered together. The network overhead is marginal, at least with respect to round-trips. If you mean round-trips when updating a small part of an object, then it is true that RESTful architectures make the path-of-least-resistance to simply PUT the full, updated resource each time it is updated. REST can work with patches, but it takes extra design effort - e.g. assigning a resource ID to each patch, and modeling the integrated resource. (GIT seems a decent example of a relatively RESTful model that uses patches.) REST was a simplification of HTTP. I am merely reporting backlash against > REST. REST is not a simplification of HTTP. (Maybe you're discussing a simplification of REST?) REST isn't even a protocol; it's a set of constraints on potential architectures. There are RESTful architectures and communication models that HTTP does not efficiently or effectively support, such as publish/subscribe or temporal data or transactions. Recently, WebSockets and Socket.IO have helped fill the pubsub gap. I have read some of the backlash against REST. But what I have read, I have not found credible. Mostly, it seems to be people who don't know RESTful idioms and design patterns, and who aren't interested in learning. They know non-RESTful solutions, and those work well enough most of the time. It isn't always clear that REST will offer an advantage, especially since REST's advantages are observed only in-the-large (extension, integration, network disruption, etc.) which is often far removed from the immediate problem.
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
