4 ms·

REST does have an advantage over SOAP in that it more easily takes advantage of the properties of the HTTP over which it runs: verbs, caching, etc. With REST i

REST does have an advantage over SOAP in that it more easily takes advantage of the properties of the HTTP over which it runs: verbs, caching, etc. With REST it's very easy to separate requests which change data from those which don't. Also, it's usually more concise. I think it's easier to code for REST than SOAP, although, by choice, I've done more of it. I have worked on some SOAP processes; while I concede it's easier to drag-and-drop SOAP objects in an IDE, the verbosity of the ensuing transactions makes it easy to overlook errors and much harder to fix them. It may be more fashionable to use REST (although I know of some circles where the opposite is true) but just because a trend is growing doesn't means it's bad. REST seems like more of a grass-roots trend while SOAP is more something that's sold to its users (that's just my impression; I'd be glad to hear arguments to the contrary.) There are a lot of technologies you could describe as more "fashionable" because their use is growing - but their intrinsic merits or suitability for an emerging purpose might be the cause of that - e.g. the web, email, pork-based cocktails. Er, strike that last one.

benreesman 19y ago
I'm not generally an advocate for SOAP. SOAP is good for basically one thing, which is sending Java/C# objects over HTTP and having them arrive on the other side looking the way you expect. My preference for languages like JavaScript leads to a preference for lightweight (mostly JSON-bearing) web services that most people would call REST. I agree that SOAP has been the subject of way too much promotion of the part of tools vendors trying to sell bloated web-services stacks. The reason for my rant is that REST has become a battle-cry in some kind of reactionary anti-vendor uprising, which obscures the issue. The word REST has a very precise meaning and almost all of the celebrated 'REST' services (Flickr, Amazon, Facebook, etc.) fail to meet the criteria. Those services are just lightweight RPC over HTTP, and there's nothing wrong with doing a service like that. For client programs written in 'dynamic' languages, those kind of services are preferable. REST is for documents, and time spent trying to find the 'resource' to be POSTed to in 'finalize this multi-step transaction between these two interest-bearing accounts' is time wasted. The linguistic gymnastics necessary to jam an RPC peg into a CRUD hole just make the service developer look silly. Cheers.
- johnm 19y ago
  Indeed, a lot of the services touted as RESTful are less RESTful and more RPCish. REST has certainly become a fad term that's used to hype that anti-SOAP juggernaut and that's led to a lot of confusion since so many of the folks doing the yapping don't really understand REST. Your confusion (whether you've read Roy's dissertation or not) seems to be a fairly common one for people coming from an experienced RPC mindset. I had a similar conversation at SDWest after my talk on REST with a SOAPer -- he too was missing the point that terms like "document" and "resource" are much more abstract in REST than what the general English meaning implies -- particularly to people who's existing experience with RPC approaches like SOAP and CORBA before that gives them a very different and, arguably, much more concrete terminology for RPC.

benreesman 19y ago

I'm not generally an advocate for SOAP. SOAP is good for basically one thing, which is sending Java/C# objects over HTTP and having them arrive on the other side looking the way you expect. My preference for languages like JavaScript leads to a preference for lightweight (mostly JSON-bearing) web services that most people would call REST. I agree that SOAP has been the subject of way too much promotion of the part of tools vendors trying to sell bloated web-services stacks. The reason for my rant is that REST has become a battle-cry in some kind of reactionary anti-vendor uprising, which obscures the issue. The word REST has a very precise meaning and almost all of the celebrated 'REST' services (Flickr, Amazon, Facebook, etc.) fail to meet the criteria. Those services are just lightweight RPC over HTTP, and there's nothing wrong with doing a service like that. For client programs written in 'dynamic' languages, those kind of services are preferable. REST is for documents, and time spent trying to find the 'resource' to be POSTed to in 'finalize this multi-step transaction between these two interest-bearing accounts' is time wasted. The linguistic gymnastics necessary to jam an RPC peg into a CRUD hole just make the service developer look silly. Cheers.

johnm 19y ago
Indeed, a lot of the services touted as RESTful are less RESTful and more RPCish. REST has certainly become a fad term that's used to hype that anti-SOAP juggernaut and that's led to a lot of confusion since so many of the folks doing the yapping don't really understand REST. Your confusion (whether you've read Roy's dissertation or not) seems to be a fairly common one for people coming from an experienced RPC mindset. I had a similar conversation at SDWest after my talk on REST with a SOAPer -- he too was missing the point that terms like "document" and "resource" are much more abstract in REST than what the general English meaning implies -- particularly to people who's existing experience with RPC approaches like SOAP and CORBA before that gives them a very different and, arguably, much more concrete terminology for RPC.