SOAP or REST for Web Services? [closed]

Question

Is REST a better approach to doing Web Services or is SOAP? Or are they different tools for different problems? Or is it a nuanced issue - that is, is one slightly better in certain arenas than another, etc?

Bounty-Edit:

Now, almost three years later I would like to ask this question again - offering a bounty to encourage an indepth answer. I would especially appreciate information about those concepts and their relation to the PHP-universe and also modern high-end web-applications.

Answer 1

My general rule is that if you want a browser web client to directly connect to a service then you should probably use REST. If you want to pass structured data between back-end services then use SOAP.

SOAP can be a real pain to set up sometimes and is often overkill for simple web client and server data exchanges. Unfortunately, most simple programming examples I've seen (and learned from) somewhat reenforce this perception.

That said, SOAP really shines when you start combining multiple SOAP services together as part of a larger process driven by a data workflow (think enterprise software). This is something that many of the SOAP programming examples fail to convey because a simple SOAP operation to do something, like fetch the price of a stock, is generally overcomplicated for what it does by itself unless it is presented in the context of providing a machine readable API detailing specific functions with set data formats for inputs and outputs that is, in turn, scripted by a larger process.

This is sad, in a way, as it really gives SOAP a bad reputation because it is difficult to show the advantages of SOAP without presenting it in the full context of how the final product is used.

Answer 2

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 3

I know this is an old question but I have to post my answer - maybe someone will find it useful. I can't believe how many people are recommending REST over SOAP. I can only assume these people are not developers or have never actually implemented a REST service of any reasonable size. Implementing a REST service takes a LOT longer than implementing a SOAP service. And in the end it comes out a lot messier, too. Here are the reasons I would choose SOAP 99% of the time:

1) Implementing a REST service takes infinitely longer than implementing a SOAP service. Tools exist for all modern languages/frameworks/platforms to read in a WSDL and output proxy classes and clients. Implementing a REST service is done by hand and - get this - by reading documentation. Furthermore, while implementing these two services, you have to make "guesses" as to what will come back across the pipe as there is no real schema or reference document.

2) Why write a REST service that returns XML anyway? The only difference is that with REST you don't know the types each element/attribute represents - you are on your own to implement it and hope that one day a string doesn't come across in a field you thought was always an int. SOAP defines the data structure using the WSDL so this is a no-brainer.

3) I've heard the complaint that with SOAP you have the "overhead" of the SOAP Envelope. In this day and age, do we really need to worry about a handful of bytes?

4) I've heard the argument that with REST you can just pop the URL into the browser and see the data. Sure, if your REST service is using simple or no authentication. The Netflix service, for instance, uses OAuth which requires you to sign things and encode things before you can even submit your request.

5) Why do we need a "readable" URL for each resource? If we were using a tool to implement the service, do we really care about the actual URL?

Need I go on?

Answer 4

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 5

1.From my experience. I would say REST gives you option to access the URL which is already built. eg-> a word search in google. That URL could be used as webservice for REST. In SOAP, you can create your own web service and access it through SOAP client.

2. REST supports text,JSON,XML format. Hence more versatile for communicating between two applications. While SOAP supports only XML format for message communication.

Answer 6

REST is an architecture, SOAP is a protocol.

That's the first problem.

You can send SOAP envelopes in a REST application.

SOAP itself is actually pretty basic and simple, it's the WSS-* standards on top of it that make it very complex.

If your consumers are other applications and other servers, there's a lot of support for the SOAP protocol today, and the basics of moving data is essentially a mouse-click in modern IDEs.

If your consumers are more likely to be RIAs or Ajax clients, you will probably want something simpler than SOAP, and more native to the client (notably JSON).

JSON packets sent over HTTP is not necessarily a REST architecture, it's just messages to URLs. All perfectly workable, but there are key components to the REST idiom. It is easy to confuse the two however. But just because you're talking HTTP requests does not necessarily mean you have a REST architecture. You can have a REST application with no HTTP at all (mind, this is rare).

So, if you have servers and consumers that are "comfortable" with SOAP, SOAP and WSS stack can serve you well. If you're doing more ad hoc things and want to better interface with web browsers, then some lighter protocol over HTTP can work well also.