Why prefer REST over SOAP?

Question

If I need a web service to pass back and forth a complex object, is there a reason I should prefer SOAP over REST? Here is an example of the possible SOAP message:

Answer 1

I view SOAP and REST as orthogonal APIs, designed to do different things.

SOAP is basically a fancy RPC, so if you want to send a computation request over to the server and get the result back, you use SOAP. If it would be local, it would be a method call to an object instance.

REST is a way to create, retrieve, update and delete remote objects, not in the sense of POO, using a uniform API. If it would be local, it would be like working with a file.

So they actually respond to different needs. You can bastardize one to do the work of the other, but you mangle the meanings.

Answer 2

Your first requirement of "passing back and forth a complex object" constrains your architecture to eliminate many of the benefits of REST. SOAP is designed for accessing remote objects, REST is not. REST supports passing media-types as simple as text/plain, which is far more primitive than dealing with an object.

If you haven't seen it already, this question and its answers cover most of the REST vs SOAP issues.

Answer 3

If you develop both the service and the client, using SOAP is as easy as REST (actually easier).

You may prefer SOAP over REST if these conditions meet:

• The entire service API is complex, not just one object.

• The service is used within a relatively small network, and performance is not an important requirement.

• You decide to spend the minimum amount of time to develop both the service and the API documentation.

Answer 4

One major benefit of REST is that all you need to call and use it is a browser and a HTTP stack - pretty much every device and machine has that. So if ease of use and reach are you main goal - use REST.

One of the major benefits of SOAP is that you have a WSDL service description and you can pretty much discover the service automatically, and generate a useable client proxy from that service description (generate the service calls, the necessary data types for the methods and so forth).

So if discoverability and a strict, formal service description are more important to you, use SOAP (with the downside that you need a full-fledged SOAP client to call your service - your web browser won't be sufficient).

SOAP isn't harder to use - but it's just not quite as "pervasive" in terms of being available - any browser can call a REST service and get an answer - but then it needs to parse and interpret that response. SOAP gets nice data structure, but you need a SOAP client for this.