Ask YC: is SOAP vs. Rest the new Emacs vs. Vi?
I've noticed the SOAP vs. REST - style webservice debate pop up again and again over the last few years. Which style of webservice do you prefer to offer/use? Why?
SOAP is for people who bought the "XML is the universal language" line of bullshit.
REST is for people who know how HTTP actually works.
That's not to say that there needs to be a war, there's no reason why both can't be implemented, though REST is definitely (as you assert) suited to HTTP.
REST is the only thing that has been actually proven to work at internet scale.
SOAP is just the latest version of CORBA, for the web.
Also, note that depending on what format the underlying data is in, using JSON can actually be worse for performance than POX (escaping, etc.).
Read the text of a SOAP transaction sometime. Or, more realistically, just read the first kilobyte or so. It's ridiculously over-engineered, and should just never be used. REST is a good example of how much simpler it could be.
After working with both (admittedly only a bit), I quickly decided REST was just far simpler.
Is there specific reasons you see advantages in some SOAP capabilities that you don't think REST would handle well?
From the server development point of view: SOAP is a giant pain. Randomly selected SOAP implementations are just not likely to interoperate. We eventually coaxed PHP5's SOAP server stuff into talking to both .NET 2.0 and Java (with Netbeans 5.5's J2EE libs) clients - IIRC we recommend SOAP 1.0 for one, and SOAP 1.1 for the other.
A week after we finished Netbeans 6.0 was released, and the SOAP client stuff that's bundled with it wouldn't play well with our server.
From the client end: /if/ you can actually talk SOAP successfully, things work nicely. You just call the generated stubs and the RPC happens transparently. If I was calling our web service from C# I would choose SOAP every time.
The REST stuff would be a pain to use if you had to use the DOM to read the XML that comes back, because, well, the DOM is painful. If parsing what comes back isn't a pain, REST works well. For internal clients, we prefer REST/JSON with the standard PHP json parser.
I think the (sane) pro-REST argument can be summed up in the following: 'HTTP is a wonderful way to do CRUD operations over a network. Wouldn't it be cool if there was a catchy word to remind people that HTTP has a lot more to it than most people are aware of?'. This bollocks about REST being able to replace RPC is like having an argument about whether cars of airplanes are a better way to get around. And please stop torturing your service models to look like URLs just to be fashionable (I know, if I want upmod a comment I can POST to /comment/1234/karma/new! No, 'Upmod' is a distinct verb that doesn't have anything to do with GET or POST or PUT or HEAD or DELETE). If the thing you are modeling isn't a document in any sense, then don't try to model it as one.
What I think people really mean when they say REST is 'ad-hoc RPC over HTTP using reasonably lightweight serialization', which is quite a lovely idea in its own right. The decision about using SOAP or a more lightweight RPC really boils down to the languages on each side of the wire. If the languages are structurally typed with object literal syntax then you want to use something lightweight, as the impedance mismatch between a literal Ruby datastructure and JSON is low. If you are connecting two nominally typed (often early bound) languages then you want SOAP, because if you're into that bondage and discipline thing then you need a WSDL to make sure that no one's boundaries get crossed. And pulling the result out of an HTTP response in Java is a lot easier with Axis than trying to parse some loosely specified JSON blob (unless you're coding in Perl, in which case I'll take the JSON blob any day).
Don't debate SOAP/REST, if you must have some silly religious debate between two technology stacks which are both reasonable tools well suited to certain activities then at least debate Java/Python, the appropriate choice of RPC philosophy sort of falls out.
Re: There are other verbs that need to be applied over a network.
Please name one that's actually needed.
My view of REST is narrow only in the sense that I've actually read the document where the term originated, which gives a rather precise (in places mathematically precise) definition of the term. If this level of rigor interests you then you can find this document at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch.... There only thing that is 'historical' about RPC is the thousands of real-world applications implemented in this style in every conceivable area of distributed computing over the last 3 or 4 decades. Whole programming languages both academic (Newsqueak) and industrial (Erlang) are premised on the notion of distributed message passing and you will be hard pressed to find any nontrivial distributed system that doesn't require the ability to invoke a verb over the network (including HTTP). From Fielding's dissertation:
'The primary distinction between network-based architectures and software architectures in general is that communication between components is restricted to message passing [6], or the equivalent of message passing if a more efficient mechanism can be selected at run-time based on the location of components [128].'
HTTP itself is a form of RPC, with distinct named methods and a way of passing arguments and retrieving results. Hard-line REST advocates fall into one of four categories:
1) They believe that HTTP is a wonderful RPC protocol for doing CRUD on entities that can be roughly called 'documents', but would never dream of trying to torture some dramatically different domain into this model. When they are writing services that are document processing services they write them in a 'RESTful' style, and they otherwise never do. 2) They believe that all network transactions can be sensibly accomplished with a model that has only GET, PUT, POST, HEAD and DELETE, and that uses them as originally intended. 3) They believe that any software system that can't be accomplished as with (2) above isn't worth writing. (Web 2.0 with Rails anyone?) 4) They don't know what REST means.
If #2 describes someone then he or she is inexperienced or stupid or both, if #3 describes someone then he or she is a fashion-conscious Web 2.0 asshole who will only ever receive money that came from a venture capitalist and never money that came from a customer. Ever. And if #4 describes someone then he or she really ought to read the literature before posting flippant drive-by commentary to Hacker News in what can only be some lame attempt at karma-whoring on the fashionability of the word 'REST'.
> Please name one that's actually needed.
Before replying to this I need to make it explicitly clear that I can only reply to what I think you're actually saying, so excuse (and correct) me if I reply to something that you didn't actually say. It sounds to me like you're proposing that GET, PUT, POST, HEAD, and DELETE are the only verbs that anyone should ever be interested in invoking over a network. Now there is a sense in which they might be sufficient for most transactions since you can attach an arbitrary payload to a POST and receive and arbitrary reply, but I think almost anyone would agree that this falls under the point made in my original post about the fact that people actually just want lightweight RPC when they talk about REST.
For the sake of argument I'm happy to propose something that people might like to do with a web-service that doesn't fit a document CRUD model: play chess. Now while you may be able to GET a description of the current board with some resource identifier like /chess/game/1234/board, you will no doubt also want to MOVE and maybe even CONCEDE, and the moment that you've started POSTing to URLs that look like /chess/game/1234/move or /move/new you're right back to POSTing to a URL with another method name in it, i.e. lightweight RPC over HTTP and it's not REST anymore. The chess example is arguably contrived (and arguably not) but it doesn't take much imagination to start picturing web services for the remote compilation of code, or the provisioning of mobile devices, or calibration of remote underwater sensors. Just because a bunch of people have decided that social-networking is the most demanding application that we as developers should ever contemplate doesn't mean that the ability to do distributed message passing and procedure call is obsolete. Plenty of people are making plenty of money doing just that.
My assertion is not that it is impossible to torture some domain into a document centric model, I'm just saying that the limit of your motivation for doing so as the distance from 'document' to your specific domain goes to infinity is 'fashion'.
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.
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.
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.
Anyone know a nice way to expose a webservice as SOAP/REST/XML-RPC & write the documentation automatically?
Good RESTful approaches are actually self-documenting. As the example from my recent talk on REST at SD West shows, it's really easy to support human discoverable (i.e., well documented) RESTful solutions. In my example, hitting the root resource returns a page (in html or text) that shows how to interact with the resource with actual examples. That's way better then some horribly verbose WSDL that somebody is going to have to look up.
More seriously, another problem with the SOAP approach is that a lot of the toolchain'ish malarky around it hides reality from the developers and so they tend to create even worse abominations.
The WSDL along with JAVA doc does give some good information about the available calls, but I think having a few client examples in a couple langauages would probably benefit more users.
Or maybe I'm just venting about my shitty week at work :)
What are some of the bad implementation problems you've experienced or heard about? Btw, I'm definitely not asking this to challenge the truth of your statement (ie., I'm not looking for a response to pick apart and argue - I would genuinely like to hear about some of the pitfalls you've seen).
From previous experience in the biological field I saw great plans, lovely (& expensive) plans to develop grand services in SOAP ... that never actually materialized ... & were converted to REST spitting out standard files.
I think the ideas of SOAP, WSDL & Co are actually very interesting but as a WS consumer I've come to shun SOAP services.
In my opinion, human discoverability & excellent documentation are core to any webservice. Maybe throw in some example implementations or lightweight libraries specific to your service.
There's very little on the REST side that's being sold (but, for good and bad, people are figuring out how to lie about that, too).
<humour>
there are people who use soap,...and then there's the REST of us :D
</humour>