SOAP and REST are not interchangeable


Recently I saw this question posted in a forum: “Does have better performance than ”?

This question is symptomatic of a fundamental misunderstanding of REST, I think. SOAP is a particular protocol used to implement RPC functionality. REST, on the other hand, is not a technology or protocol, but an architectural style. Systems that were built with the REST architectural style are fundamentally different from RPC based systems. For REST, we think in resources and data. For RPC we think in methods and actions. You can’t just swap one out for the other, because they are not even in the same category of things.

Comparing the performance of REST to SOAP is like asking: “What tastes better? ‘Stir fried’ or ‘zucchini’?” or “Which one is better? ‘Darth Vader’ or ‘Star Trek’?” Those question just don’t make any sense. People who think that they do are probably the same who think that REST is nothing but “RPC via URI”, which of course it is not.

You can ask whether a RESTful system, using HTTP as protocol, would have certain advantages or disadvantages compared to an RPC based system, using SOAP (over HTTP) as protocol. And even then you need to look at the system you are trying to implement and its specific requirements.

As far as performance is concerned: You can’t just say that “REST is faster/slower than SOAP”, since the two systems you deal with exhibit entirely different usage patterns and underlying architectures. If you talk about network connections, latency, use of additional libraries and stacks in that context, you still think that there is a 1:1 mapping somehow. You need to set all of that aside. Instead, to compare performance you first need to take a step back:

  • Ask yourself whether your system can be implemented as an RPC based system? Can it also be implemented as a resource oriented system? If so, which approach is more natural to the problem at hand?
  • Which of these two would result in a more natural work flow for you and your clients?
  • Does one of them offer other benefits (scalability, reliability, etc.) aside from those concerns?
  • Which of all of these things is most important to you?

The answers to these questions need to be considered. It’s certainly not as simple as asking if “REST has better performance than SOAP”. The two are not interchangeable like engines in a car.

We'd love to hear your opinion on this post

3 Responses to “SOAP and REST are not interchangeable”

  1. While I surely share the sentiment that a question like “Which of the two performs better, SOAP or REST?” is rather non-sensical, I strongly disagree with the notion that SOAP is an RPC technology.

    It sure used to be, back in its early days when people were actually using SOAP that way. But today it’s 2010 A.C. and in my experience the document/literal style of using SOAP is prevalent. And this style forces you to think not in terms of remote procedures to be invoked but rather of documents to be exchanged.


  2. If they are not interchangable, Can they be used one on another ? May be you can give examples about that.

  3. When looking at it from how to expose information to the outside world you can actually make somewhat of a comparison. If you look at the typical way SOAP and REST services get implemented you can make the observation that REST typical leans towards more requests and smaller smaller payloads vs soap with fewer requests and bigger payloads. The revolves around the fact that rest promotes the notion of a resource where as with soap you generally get an aggregated set of information from several resources in one. Both can be bended to make it the other way around, of course.

    Regardless, I agree with Olaf, SOAP+document literal is what any new service uses. And that is the message that should be spread, because some people didn’t get the memo. Comparing performance is just a symptom of people not knowing document literal.