Why SOAP can't use HTTP caching mechanisms

Question

I am making a transition from SOAP to REST, and I would like to convince my colleagues that this is a good move. We don't need the extra security mechanisms that SOAP can provide. For us the overhead of SOAP and WSDL has only proven to be a headache over the years.

Apart from the obvious simplifications, one really valuable advantage for our system would be the HTTP caching mechanisms. I have read things on the subject, but I still don't fully understand why these caching mechanisms can't be applied to SOAP messages.

Is it simply because REST by convention encodes all the parameters in the url? Since a GET call can also have a body with parameters, I understand that it's not restricted for REST, but the caching mechanisms don't work if you do so?

Solution 1

SOAP, when using HTTP as the transfer mechanism, is sent via HTTP POST requests. As HTTP POST is non-idempotent, it is not cached at the HTTP level.

REST may be cached, provided the requests in question are idempotent ones: GET, PUT and (theoretically) DELETE. Any POST requests still won't be cached. That said, if you are planning to do a lot of work with this, you should look into how caches check whether they are still valid. In particular, the ETag header will be a good way to implement caching providing you've got a cheap way to compute what the value should be.

Is it simply because REST by convention encodes all the parameters in the url? Since a GET call can also have a body with parameters, I understand that it's not restricted for REST, but the caching mechanisms don't work if you do so?

REST does not prescribe any particular mechanism for how to encode request parameters in the URL. What is recommended is that clients never do any URL synthesis: let the server do all the URL creation (by whatever mechanism you want, such as embedding within the path or as query parameters). What you definitely shouldn't do is have a GET where the client sends a body to the server! Any cache is likely to lose that. Instead, when that request doesn't correspond to a simple fetch of some resource, you POST or PUT that complex document to the server and GET the result of the operation as a separate stage.

A POST of a complex document that returns the result of the operation as another complex document is pretty much how SOAP is encoded. If you're tempted to do that, you might as well use SOAP directly as that's got much more mature tooling in many languages. If you want to run REST that way, you're probably doing it wrong somewhere…

Solution 2

Stating that POST requests are non-idempotent in general is not correct. POST should be used for non-idempotent operations but SOAP is not really using the HTTP correctly and as the result of that it can happened, that POST is used for idempotent operation - for example for fetching an entity by ID (which you would normally use GET for).

Also according to this: Is it possible to cache POST methods in HTTP? (check the answer of reBoot), POST requests is possible to cache according to RFC. It may not be implemented very well by browsers and proxies though. Anyway if you add appropriate HTTP headers, SOAP over HTTP messages should be possible to cache using HTTP caching mechanisms.

Solution 3

Another reason could be that SOAP URI is always the soap server, its not determining which resource needs to be cached or what is the resource. So Cache server cannot perform caching of something it don't know. However, REST has URI for each resource (can be multiple URIs for same resource), which helps caching server to perform its job.

On top of this, as mentioned in other answers only some of HTTP verbs are used for caching like GET, PUT etc (mostly GET).

Comments

[Thijs Koerselman]

Thanks Donal, I understand how it works now and thanks for the link. Most of my api will be simple GET and I don't need to pass the parameters encoded in the body. I was confused because it IS allowed and then it looks a lot like SOAP over http. I now understand that I should definitely avoid doing that.

[Thijs Koerselman]

I don't agree that SOAP has very mature tooling in many languages. I have tried to use soap from Javascript and Lua to talk to a Java server. There are mature tools for Java but they even changed how strict they were over time, updates to CXF more then once broke the communication with other clients that did things slightly different. Those other libraries were often maintained by one or few people that only supported the specification partially, with me having to hack them in order to play nice with CXF. For the fairly basic stuff that we do, SOAP turned out to be a major headache.

[Thijs Koerselman]

REST simplifies things for me a LOT and I'm glad I can move on:)

[Donal Fellows]

@0x80 JS has one of the poorest SOAP toolings; many languages have much richer tool chains. They tend to be there because they're used in corporate code (and message busses and so on) so people have paid for the tools to be developed to a high degree. JS has had relatively little use on the back end (node.js is pretty new by comparison) so it hasn't been pushed that way. (I don't know of all that many people doing complex web programming in Lua, but there I'd expect someone to use C++ SOAP bindings and map them into Lua as an extension library.)

[Thijs Koerselman]

You're probably right. My experience just comes from those 2 languages and they both have poor soap tooling. But I was also surprised at how CXF tended to change it's behavior over time. For us SOAP is just not a good choice since our clients are now all JS and we don't need the additional security. Being able to use JSON instead of XML is also a nice pre when using JS of course.