Rest vs. Soap. Has REST a better performance?

Question

I read some questions already posted here regarding Soap and Rest and I didn't find the answer I am looking for. We have a system which has been built using Soap web services. The system is not very performant and it is under discussion to replace all Soap web services for REST web services. Somebody has argued that Rest has a better performance. I don't know if this is true. (This was my first question) Assuming that this is true, is there any disadvantage using REST instead of Soap? (Are we loosing something?)

Thanks in advance.

Answer 1

SOAP requires an XML message to be parsed and all that <riduculouslylongnamespace:mylongtagname>extra</riduculouslylongnamespace:mylongtagname> stuff to be sent and receieved.

REST usually uses something much more terse and easily parsed like JSON.

However in practice the difference is not that great.

Building a DOM from XMLis usually done a superfast superoptimised piece of code like XERCES in C++ or Java whereas most JSON parsers are in the roll your own or interpreted catagory.

In fast network environment (LAN or Broadband) there is not much difference between sending a one or two K versus 10 to 15 k.

Answer 2

It all depends. REST doesn't really have a (good) answer for the situation where the request data may become large. I feel this point if sometimes overlooked when hyping REST.

Let's imagine a service that allows you to request informational data for thousands of different items.

The SOAP developer would define a method that would allow you retrieve the information for one or as many items as you like ... in a single call.

The REST developer would be concerned that his URI would become too long so he would define a GET method that would take a single item as parameter. You would then have to call this multiple times, once for each item, in order to get your data. Clean and easy to understand ... but.

In this case there would be a lot more round-trips required for the REST service to accomplish what can be done with a single call on the SOAP service.

Yes, I know there are workarounds for how to handle large request data in the REST scenario. For example you can pack stuff into the body of your request. But then you will have to define carefully (on both the server and the client side) how this is to be interpreted. In these situations you start to feel the pain that REST is not really a standard (like SOAP) but more of a way of doing things.

For situations where only relatively limited amount of data is exchanged REST is a very good choice. At the end of the day this is the majority of use cases.

Answer 3

One thing the other answers seem to overlook is REST support for caching and other benefits of HTTP. While SOAP uses HTTP, it does not take advantage HTTP's supporting infrastructure. The SOAP 1.1 binding only defines the use of the POST verb. This was fixed with version 1.2 with the introduction of GET bindings, however this may be an issue if using the older version or not using the appropriate bindings.

Security is another key performance concern. REST applications typically use TLS or other session layer security mechanisms. TLS is much faster than using application level security mechanisms such as WS Security (WS Security also suffers from security flaws).

However, I think that these are mostly minor issues when comparing SOAP and REST based services. You can find work arounds for either SOAP's or REST's performance issues. My personal opinion is that neither SOAP, nor REST (by REST I mean HTTP-based REST services) are appropriate for services requiring high throughput and low-latency. For those types of services, you probably want to go with something like Apache Thrift, 0MQ, or the myriad of other binary RPC protocols.