SOAP or REST as a Client

Question

I see multiple questions asking which is better, SOAP or REST from the development of the Web Service itself. However, not a lot of discussion of the pros/cons from the client perspective. If you were to write an Application and have a choice between two Web Service APIs that are similar in every way except one is SOAP and the other is REST, which would you choose and why? REST has the added benefit of allowing either XML or JSON, is there any other major difference between the two?

Answer 1

Wow, 10 hours and no answer so far to this question. Usually these types of questions are jumped on in an instant.

Anyway, here is bit of strange answer to your question. The choice should depend on a few things:

1. How good is the documentation for the two APIs.
2. How likely is the API to change.
3. How much time do I have to produce the client
4. How long is the client likely to be used for.
5. Does the REST api documentation consist of a list of Urls with the XML/JSON that they return?

Whichever API has the better documentation is likely to be the better API to use. This is not guaranteed, but it is a good indicator. It does not matter whether SOAP is better than REST or vice versa if the implementation is garbage you are going to suffer either way.

If this is a brand new API, created by a startup, that is likely to evolve significantly over the next year then a REST api will likely be easier to manage. SOAP apis tend to be pretty brittle and require frequent client recompilations due to the generated client proxy code.

Despite the 1001 reasons why I hate client generated proxy code, if you need to get something working really quick. Pointing your favorite IDE at chunk of WSDL will very quickly get you an object model to play with. It is definitely the fastest way to get something working.

If the client is going to be around for a number of years then I believe it is worth investing the time into producing a good REST client. A REST based approach is much more resilient to the inevitable changes that will occur over time. There are also much more options when it comes to version REST clients than SOAP based ones.

The last item is a bit of litmus test for whether the REST API is a real REST interface or not. If the documentation is a catalog of http endpoints then you can be pretty much assured that the designers don't know what REST is, so stay away from it.

Answer 2

You're making a flawed assumption.

You say:

If you were to write an Application and have a choice between two Web Service APIs that are similar in every way except one is SOAP and the other is REST, which would you choose and why?

The truth be told, a SOAP API will very likely be completely different from a REST system, so you can't really compare at this level.

REST is an architecture, not a protocol. SOAP is a protocol, but not an architecture. While possible, it's unlikely you would create a REST architecture on top of the SOAP protocol, as the SOAP payloads don't offer a lot to a REST system.

SOAP systems tend to be more RPC based, REST systems are Resource based. The difference is significant between these two, operationally and in design.

As far as using SOAP vs XML/JSON over HTTP (what many people mistakenly conflate with REST), the primary benefit of a SOAP system is the tooling available to make interfacing to and publishing from systems much easier.

Today, many IDEs and servers can readily publish and consume SOAP web services.

In Java, publish a SOAP interface can be little more that sticking "@WebService" in a file and deploying it. Consuming a web service little more than pointing the IDE at a WSDL (conveniently created for you when the web service is published), clicking a button, and having the tools create the proxies necessary to marshal data and communicate with the service.

XML/JSON over HTTP has a benefit that you will likely skip much of the boiler plate that makes automating SOAP "easy". Javascript, of course, is quite adept at consuming JSON, so if you're client space includes Web Browsers, that can be a factor.

Boiled down, if you talking Browser to Server, XML/JSON over HTTP works pretty well, an actual REST architecture can work well as well.

If you're talking RPC between servers, then SOAP is much easier to implement because of the tooling available today.