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

Answer 1

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.

Answer 2

REST allows your non-mutating operations (that generally use the GET verb) to be cached. That is, cached by the client and/or cached by proxies. This can be a huge win!

Answer 3

It is super simple and slim. You could do it with browser via http verb: GET. I haven't find a browser can manually do generic http POST request easily

Answer 4

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.

Answer 5

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.