Recently I saw this question posted in a forum: 「Does REST have better performance than SOAP」?app
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.ide
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.post
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:ui
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.this