SOAP or REST for Web Services? [closed]

Answer 1

Quick lowdown for 2012 question:

Areas that REST works really well for are:

• Limited bandwidth and resources. Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX.

• Totally stateless operations. If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it.

• Caching situations. If the information can be cached because of the totally stateless operation of the REST approach, this is perfect.That covers a lot of solutions in the above three.

So why would I even consider SOAP? Again, SOAP is fairly mature and well-defined and does come with a complete specification. The REST approach is just that, an approach and is wide open for development, so if you have the following then SOAP is a great solution:

• Asynchronous processing and invocation. If your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging.

• Formal contracts. If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction.

• Stateful operations. If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.

http://www.infoq.com/articles/rest-soap-when-to-use-each

Answer 2

I'm sure Don Box created SOAP as a joke - 'look you can call RPC methods over the web' and today groans when he realises what a bloated nightmare of web standards it has become :-)

REST is good, simple, implemented everywhere (so more a 'standard' than the standards) fast and easy. Use REST.

Answer 3

It's nuanced.

If you need to have other systems interface with your services, than a lot of clients will be happier with SOAP, due to the layers of "verification" you have with the contracts, WSDL, and the SOAP standard.

For day-to-day systems calling into systems, I think that SOAP is a lot of unnecessary overhead when a simple HTML call will do.

Answer 4

It's a good question... I don't want to lead you astray, so I'm open to other people's answers as much as you are. For me, it really comes down to cost of overhead and what the use of the API is. I prefer consuming web services when creating client software, however I don't like the weight of SOAP. REST, I believe, is lighter weight but I don't enjoy working with it from a client perspective nearly as much.

I'm curious as to what others think.

Answer 5

REST is an architecture invented by Roy Fielding and described in his dissertation Architectural Styles and the Design of Network-based Software Architectures. Roy is also the main author of HTTP - the protocol that defines document transfer over the World Wide Web. HTTP is a RESTful protocol. When developers talk about "using REST Web services" it is probably more accurate to say "using HTTP."

SOAP is a XML-based protocol that tunnels inside an HTTP request/response, so even if you use SOAP, you are using REST too. There is some debate over whether SOAP adds any significant functionality to basic HTTP.

Before authoring a Web service, I would recommend studying HTTP. Odds are your requirements can be implemented with functionality already defined in the spec, so other protocols won't be needed.

Answer 6

SOAP currently has the advantage of better tools where they will generate a lot of the boilerplate code for both the service layer as well as generating clients from any given WSDL.

REST is simpler, can be easier to maintain as a result, lies at the heart of Web architecture, allows for better protocol visibility, and has been proven to scale at the size of the WWW itself. Some frameworks out there help you build REST services, like Ruby on Rails, and some even help you with writing clients, like ADO.NET Data Services. But for the most part, tool support is lacking.