SOAP and XML-RPC or REST performance

Question

The arguments for simplicity of decisions using XML-RPC or REST are easy to understand and difficult to argue.

I have also often heard arguments that increasing SOAP overhead can significantly affect the bandwidth used and possibly even latency. I would like to see the results of a test that quantifies the impact. Does anyone know a good source of such information?

Answer 1

There are several studies that have been done regarding this that you may find informative. See the following:

• SO: Rest vs Soap Performance
• Q & A: SOAP and REST 101
• Updated SQL Server Data Services: Downloading to REST and SOAP for Northwind

There is also a (somewhat outdated) interesting talk about performance on a topic in the MSDN Forums .

In short, most of these sources seem to agree that SOAP and REST are roughly the same for general purpose data. However, some results indicate that with binary data, REST may actually be less efficient. See the links in the forum that I linked for more details on this.

Answer 2

The main influence on the speed of SOAP and REST is not related to the transmission rate, but to the possibility of caching. REST suggests using web semantics instead of trying to tunnel it through XML, so RESTful web services are usually designed to use cache headers correctly, so they work well with web standard infrastructure like proxy caching and even local caches browser. In addition, the use of web semantics means that things like ETags and automatic zipper compression are well aware of ways to increase efficiency.

.. and now you say you want tests. Well, with the help of Google, I found one guy whose testing shows that REST will be 4-6 times faster than SOAP, and another paper that also supports REST.

Answer 3

REST as a protocol does not define any form of message envelope, whereas SOAP has this standard.

Thus, to simplify it somewhat, in order to try to compare them, they are apples for oranges.

However, the SOAP envelope (minus data) is only a few k, so there should be no noticeable difference in speed provided that you retrieve the serialized object through SOAP and REST.

Answer 4

SOAP and any other protocol that uses XML usually inflates your messages quite a bit - this may or may not be a problem depending on the context.

Something like JSON would be more compact and maybe serialize / deserialize faster, but not use it solely for this reason. Do what you feel makes sense at the time and change it if that is a problem.

Everything that HTTP typically uses (if not reusing the keepalive HTTP 1.1 connection, which is not implemented by many implementations) starts a new TCP connection for each request; this is pretty bad, especially for high latency links. HTTPS is much worse. If you have many short requests from one sender to one recipient, think about how you can take this overhead.

Using HTTP for any type of RPC (be it SOAP or something else) will always incur overhead. Other RPC protocols usually allow you to open a connection.

Answer 5

The extension of the answer is "pjz".

If you get a lot of SOAP (receiving * call type) operations based on SOAP, you cannot cache them at this time. But if you were to perform the same operations using REST, there is a possibility that the data (depending on your business context) may be cached as described above. Because SOAP uses POST for its operations, it cannot cache server-side information.

Answer 6

SOAP is definitely slower. The payloads are much larger, which are collected, transported, analyzed, verified and processed more slowly.

Answer 7

I don’t know any answer to the question related to benchmarking, however, what I know about the SOAP format, yes, it has overhead, but this overhead does not increase for each request: if you have one item sent to the web -service, you have overhead + one element design, and if you have 1000 elements sent to the web service, you have an add-on + 1000 elements. Overhead occurs when an XML request is formatted for a specific operation, but each individual argument element in the request is formatted the same way.

If you stick to repeated short bursts of data (say, 500 elements), the speed should be acceptable.

Answer 8

I think the main question here is how compares RPC with SOAP.

they both perform the same communication abstraction approach, having the stub objects you work with and the primitive / complex data types that you return without knowing how all this is processed under it.

I would always prefer (JSON-) RPC because

• it's easy
• There are many great implementations for all programming languages.
• it's easy to learn / use / create
• fast (especially with JSON)

although there are reasons why you should use SOAP, i.e. if you need naming parameters instead of relying on their proper order

some additional information you get from this stackoverflow question