Why would one use REST instead of SOAP based services? [closed]

Question

Less overhead (no SOAP envelope to wrap every call in)

Less duplication (HTTP already represents operations like DELETE, PUT, GET, etc. that have to otherwise be represented in a SOAP envelope).

More standardized - HTTP operations are well understood and operate consistently. Some SOAP implementations can get finicky.

More human readable and testable (harder to test SOAP with just a browser).

Don't need to use XML (well you kind of don't have to for SOAP either but it hardly makes sense since you're already doing parsing of the envelope).

Libraries have made SOAP (kind of) easy. But you are abstracting away a lot of redundancy underneath as I have noted. yes in theory SOAP can go over other transports so as to avoid riding atop a layer doing similar things, but in reality just about all SOAP work you'll ever do is over HTTP.

RESTful services are much simpler to consume than SOAP based (regular) services. The reason for this is that REST is based on normal HTTP requests which enables intent to be inferred from the type of request being made (GET = retrive, POST = write, DELETE = remove, etc...) and is completely stateless. On the other hand you could argue that it is less flexible as it does away with the concept of a message envelope that contains request context.

In my experience SOAP has been preferred for services within the enterprise and REST has been preferred for services that are exposed as public APIs.

With tools like WCF in the .NET framework it is very trivial to implement a service as REST or SOAP.

Some relevant reading:

• Amazon Web Services Blog: REST vs SOAP
• Dare Obasanjo writes often about REST

I'll assume that when you say "web services" you mean SOAP and the WS-* set of standards. (Otherwise, I could argue that REST services are "web services".)

The canonical argument is that REST services are a closer match to the design of the web - that is, the design of HTTP and associated infrastructure. Thus, using a REST service will be more compatible with existing web tools and techniques.

Of course, once you drill into specifics, you find out that both approaches have strengths in different scenarios. Is it those specifics that you're interested in?

The overhead isn't that important as good architecture.

REST isn't a protocol it is an architecture that encourage good scalable design. It is often chosen because too much freedom in RPC can easily lead to a poor design.

The other reason is predictable cost of RESTful protocols over HTTP because it can leverage existing technologies (mainly proxies). RPC initial cost is quite low but it tend to increase significantly with load intensification.

REST is implementation-agnostic and much more transparent, and this makes it great for public APIs, especially for big websites like Flickr, Amazon or Digg that are using their APIs as marketing tools and really want people to consume their data. They don't want to be hand-holding 1000s of novice developers who are trying to debug their scripting language of choice's buggy SOAP library.

Versus SOAP and WSDL, which are better for internal applications, where you have drop-in libraries and known clueful people on both ends. (And you maybe don't have to care about things like Internet-scale load-balancing, HTTP caching etc.) Then you get APIs that are self-documented, preserve types etc. with zero work.

Got to read Roy Fielding's most excellent dissertation on the topic. He makes an excellent case and was definitely WAY ahead of his time when he wrote it (2000).

Steve Vinoski's blog and his latest articles are definitely worth perusing. He's a former CORBA guru, who wrote probably the best book on the subject with Michi Henning, "Advanced CORBA® Programming with C++". However, he has since seen the error of his client/server ways, and now swears by REST.