3 ms·

> once-RESTful protocols are becoming increasingly similar to WS-* How so?

by bct 18y ago

briansmith 18y ago
It is pretty common for a RESTful protocol to end up with batch-fetching and batch-updating operations. Once you add those operations, you've already violated the "uniform interface" constraint and removed all the benefits (primarily caching, authentication, authorization, and parallelism) that derive from the uniform interface constraint. Once you have batch-fetch and batch-update, those two operations can generally do everything that you usually did via individual PUT/POST/DELETE operations. So, why do you need the separate PUT/POST/DELETE operations at all? It is just more surface area for you to maintain. Now, maybe you want to combine your batch-update and batch-fetch operations into a single "batch-update-and-fetch" POST operation. Well, that is exactly what WS-* does. On the flip side, sometimes instead of batching you want to fetch or update only parts of individual resources via some extension to partial GET requests and or a PATCH method. There is currently no uniform interface for those so, just like in the case of batching, you lose all the uniform-interface benefits. Now, let's say you want to combine your partial-resource operations with batch operations over multiple resources to reduce the number of requests you receive and/or the reduce the aggregate size of requests, so you add the ability to do patching and partial-fetches to your batch-update-and-fetch mechanism. Now take a step back. Doesn't your batch-update-and-fetch-with-patch-and-partial-fetch look a lot like SOAP with WS-ResourceTransfer? It will probably look a lot like SOAP; not even the newish SOAP 1.2 that actually is somewhat HTTP cache friendly, but old school RPC-only SOAP + WS-ResourceTransfer. Look at Google's GData and OpenSocial's RESTful API for examples. And, that is totally ignoring anything to do with transactions.
- briansmith 18y ago
  OK, I want to mention one more thing. Take any WS-<star> specification, and you can probably find one or more ad-hoc proposals for adding similar features for RESTful protocols. For example, AtomPub is adding a mechanism that is almost exactly like SOAP-with-attachments, but more limited. The various HTTP message signing mechanisms like those found in Amazon's web services or the one in OAuth (and OpenID? I forget if there is a different one for that) are analogous to the various WS-Security stuff. As another example, I've seen a couple RESTful protocols that tried to define something like a simpler WS-Policy. I don't think that the WS-<star> stuff is that great either; a lot of it is really complex. But, WS-<star> stuff is all decomposed in ways that make it relatively simple to combine just the parts you need together. SOAP 1.2 isn't complicated at all. WS-Policy and WS-Security and other stuff is more complicated than it needs to be, but it isn't so complicated that it needs to be totally redone anew. And, a lot of it can be (and is) subsetted pretty easily.
- bct 18y ago
  Thanks for your detailed replies. I'm not convinced that this is a major trend, but I see your point.
- davidmathers 18y ago
  What you say makes a certain kind of sense if you think of REST as a protocol. But REST is not a protocol. There seem to be quite a few people these days who think that REST means nothing more than "uniform interface" and/or "resources". But that's only part of the picture. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch... "REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state." P.S. I'm not sure why you think batch operations are missing from REST. GET/PUT/POST/DELETE can apply just as well to collections as to individual resources.

> once-RESTful protocols are becoming increasingly similar to WS-* How so?

by bct 18y ago

> once-RESTful protocols are becoming increasingly similar to WS-* How so?

It is pretty common for a RESTful protocol to end up with batch-fetching and batch-updating operations. Once you add those operations, you've already violated the "uniform interface" constraint and removed all the benefits (primarily caching, authentication, authorization, and parallelism) that derive from the uniform interface constraint. Once you have batch-fetch and batch-update, those two operations can generally do everything that you usually did via individual PUT/POST/DELETE operations. So, why do you need the separate PUT/POST/DELETE operations at all? It is just more surface area for you to maintain. Now, maybe you want to combine your batch-update and batch-fetch operations into a single "batch-update-and-fetch" POST operation. Well, that is exactly what WS-* does. On the flip side, sometimes instead of batching you want to fetch or update only parts of individual resources via some extension to partial GET requests and or a PATCH method. There is currently no uniform interface for those so, just like in the case of batching, you lose all the uniform-interface benefits. Now, let's say you want to combine your partial-resource operations with batch operations over multiple resources to reduce the number of requests you receive and/or the reduce the aggregate size of requests, so you add the ability to do patching and partial-fetches to your batch-update-and-fetch mechanism. Now take a step back. Doesn't your batch-update-and-fetch-with-patch-and-partial-fetch look a lot like SOAP with WS-ResourceTransfer? It will probably look a lot like SOAP; not even the newish SOAP 1.2 that actually is somewhat HTTP cache friendly, but old school RPC-only SOAP + WS-ResourceTransfer. Look at Google's GData and OpenSocial's RESTful API for examples. And, that is totally ignoring anything to do with transactions.

briansmith 18y ago
OK, I want to mention one more thing. Take any WS-<star> specification, and you can probably find one or more ad-hoc proposals for adding similar features for RESTful protocols. For example, AtomPub is adding a mechanism that is almost exactly like SOAP-with-attachments, but more limited. The various HTTP message signing mechanisms like those found in Amazon's web services or the one in OAuth (and OpenID? I forget if there is a different one for that) are analogous to the various WS-Security stuff. As another example, I've seen a couple RESTful protocols that tried to define something like a simpler WS-Policy. I don't think that the WS-<star> stuff is that great either; a lot of it is really complex. But, WS-<star> stuff is all decomposed in ways that make it relatively simple to combine just the parts you need together. SOAP 1.2 isn't complicated at all. WS-Policy and WS-Security and other stuff is more complicated than it needs to be, but it isn't so complicated that it needs to be totally redone anew. And, a lot of it can be (and is) subsetted pretty easily.
bct 18y ago
Thanks for your detailed replies. I'm not convinced that this is a major trend, but I see your point.
davidmathers 18y ago
What you say makes a certain kind of sense if you think of REST as a protocol. But REST is not a protocol. There seem to be quite a few people these days who think that REST means nothing more than "uniform interface" and/or "resources". But that's only part of the picture. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch... "REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state." P.S. I'm not sure why you think batch operations are missing from REST. GET/PUT/POST/DELETE can apply just as well to collections as to individual resources.