11

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?

Books
  • 5,163
  • 5
  • 19
  • 18
  • 7
    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 Nov 24 '10 at 12:05
  • How else would you pass a complex object? Sure I could use JSON, but that isn't enough to justify abandoning SOAP for REST. The object may contain nested fields and that may not translate well to a URL. – Books Nov 24 '10 at 12:08
  • 1
    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). – Chris Morgan Nov 24 '10 at 12:33

4 Answers4

9

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.

Community
  • 1
  • 1
Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • 2
    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. – jfs Dec 16 '11 at 16:44
  • 1
    @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. – Darrel Miller Dec 16 '11 at 18:28
5

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.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
  • But do you really need a full fledged SOAP client? Can't I just copy the message, fill in the blanks, and POST it to the endpoint? Wouldn't that be almost the "same" as a REST client? I'm not trying to make it sound like I'm against REST -- I want to be convinced. – Books Nov 24 '10 at 12:14
  • @marc_s, "but then it needs to parse and interpret that response", would not use of COD using JavaScript solve this problem? – Anders Nov 24 '10 at 12:15
  • @Ashley: if you want to talk to a SOAP service, you need a SOAP client, as far as I know. I don't think you can "just POST" to that URL (never tried it myself, anyway) – marc_s Nov 24 '10 at 12:41
  • @Anders: maybe, to a degree - but a REST service (at least today) typically doesn't have a machine-discoverable description of what it offers in terms of methods / URLs / data. You as a programmer need to *know* that, somehow, e.g. by reading, understanding and following some documentation. – marc_s Nov 24 '10 at 12:42
  • @marc_s: If you take a look at [this](http://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius) web service, you can see there are sample SOAP calls, which look like regular POSTs to me, but with an extra SOAPAction header. – Books Nov 24 '10 at 12:56
  • @marc_s Actually, REST does have a discovery mechanism. It is just built into the http headers and responses. The difference is that it is a dynamic, runtime discovery mechanism instead of static design time mechanism like WSDL. It does mean that you cannot autogenerate client proxy classes with REST, however in most cases you really wouldn't want to do that anyway as it creates too much client server coupling. – Darrel Miller Nov 24 '10 at 14:19
  • 1
    @Darrel Miller: do you have any links illustrating that?? Be interesting to check out... – marc_s Nov 24 '10 at 15:47
  • @Ashley: thanks for that link - so it looks like it might work (unless the guys in this sample have done extra work to make this possible) - try it! See if it does work. – marc_s Nov 24 '10 at 15:49
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.

ddalex
  • 436
  • 4
  • 7
1

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.

Huy
  • 46
  • 5