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:

<soap:Envelope>
  <soap:Header>
    <Credentials>
      <User>Joe</User>
      <Password>abc123</Password>
    </Credentials>
  </soap:Header>
  <soap:Body>
    <MyComplexBusinessObject>
      <Search>
        <First>Joe</First>
        <Last>Smith</Last>
      </Search>
      ...
      ...
    </MyComplexBusinessObject>
  </soap:Body>
</soap:Envelope>

Using REST, I would be asking the client to POST the following xml and authenticate using Basic Authentication:

<MyComplexBusinessObject>
  <Search>
    <First>Joe</First>
    <Last>Smith</Last>
  </Search>
  ...
  ...
</MyComplexBusinessObject>

The SOAP message is slightly more complicated, but not by much. They are still both XML, but SOAP comes with a WSDL and most programming environments will generate proxy classes for you. However, most people I talk to say I should use REST instead because it's easier to use. But I don't see how SOAP is any harder to use.

Am I missing something?

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

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.

View more solutions

Comments

[Chris Morgan]

Why XML at all is the point. JSON would be much neater (from a programming perspective) and more compact. [{'First':'Joe','Last':'Smith'},...]

[Chris Morgan]

actually, for this case, a better match would be just POSTing to /search with standard POST variables; 1=Joe,Smith&2=John,Citizen&... for example. If you're wanting more than just search, you've come to the wrong shop - SOAP may take everything at the one URL, but REST isn't like that - one URL per thing (and if you could just do /search/joe+smith or something like that it'd be better still).

[jfs]

Most RESTful services can be described as "passing back and forth complex objects" aka REpresentational State Transfer. And no almost none of them use text/plain. REST is more document-oriented and SOAP is more RPC-like solution.

[Darrel Miller]

@J.F.Sebastian Most services that claim to be RESTful are in fact not. Passing an object between a client and server implies a sharing a type, along with certain semantics, that are not declared explicitly in the message. That violates the constraints of REST.