SOAP vs. REST

Posted on November 21, 2002

Oh, boy… Dave Winer‘s at it again.

Today he’s pontificating on the differences between two philosophies of how applications should communicate over the Internet. And, as he’s been doing a lot lately, he’s busied himself throwing a hand grenade into the discussion.

As I mentioned, there are two approaches in contention. One of these, SOAP (named after its standard implementation, which is called the Simple Object Access Protocol), basically posits that Everything Should Be a Program — i.e., information should be stored in programs with methods that I can send a request to and get a response back. That’s how SOAP works, and it’s a paradigm that’s very familiar to programmers, who have been working with it forever on their own networks — what makes SOAP compelling is the idea that I can do that to any system on the Web that’s set up to support it.

The other model, Representational State Transfer (REST), has a different approach. It essentially argues that Everything Should Be a URL — that I should be able to encode a request for data entirely into a single Web address, which, if queried, will return the data I seek.

This is different from the SOAP method, which requires me to format my request as an XML “message”, and then send the message to the data source, which unpacks it, translates it into the native language of whatever software it’s running, carries out the request, translates the results back into XML, and sends it back to me in another XML message. With REST, all the complexity is encapsulated into a Web address. Take this link, for example, which, if you click it, will query Amazon’s Web service (which offers a REST interface) for books on ColdFusion:

http://rcm.Amazon.com/e/cm?t= instantcoldfu-20&mode=books&search=ColdFusion&l=st1&p=102&o=1&f=xml

If REST sounds simpler to you, that’s because it is. And it has the other advantage of making searches uniquely addressable: you can bookmark that link I just showed you, and the bookmark will always take you to the latest results of the search.

REST isn’t perfect, though. If you’re a software developer, SOAP is a much more natural approach: rather than cram all your search parameters into a looooong URL, you can use one of the many freely available SOAP “toolkits” to automatically translate instructions from your programs into SOAP messages to query remote Web services, and to translate the reply you get back. SOAP can also be asynchronous; you’re not just limited to responses that give instant feedback. I can send a SOAP message by e-mail, for example, and the process that receives it can do something that’s time-consuming, and just e-mail me back the results whenever it’s done. You can’t do that with REST — or rather, you can, but it’s very difficult (unlike SOAP, which is “protocol-neutral”, meaning it doesn’t care if it gets sent over the Web or e-mail or by pony express).

Now, Winer is one of the authors of the SOAP protocol (and one of its leading advocates), so it’s not surprising that he prefers the SOAP approach over REST. But his language in expressing this preference is needlessly inflammatory: “REST was a retrofit by people who don’t like personal computers to try to stop progress in building GUI software that ran over the Internet… the people who promote REST aren’t people who actively develop software. If they were there would be no ‘debate.’ ”

Now, come on. SOAP is great — I love it (I use it to provide the Google search results on the home page of this site). It’s easy to develop with and provides a powerful new way for programmers to access information. But REST has some nice things about it as well, the primary one being its addressability (there is no “address” at which a procedure call resides).

Is SOAP nice? Yep. Is REST nice too? You betcha. I’m with Dave that I prefer SOAP for my everyday work. But there’s no need to dismiss REST advocates out of hand. Doing so just inflames arguments and doesn’t help anybody.