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

Attended an interesting demo on REST today, however, I couldn't think of a single reason (nor was one presented) why REST is in anyway better or simpler to use and implement than a SOAP based Services stack.

What are some of the reasons Why anyone in the "real world" use REST instead of the SOAP based Services?

Solution 1:

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.

Solution 2:

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

Solution 3:

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?