Performance of SOAP vs. XML-RPC or REST

Question

The arguments about the simplicity of solutions using XML-RPC or REST are easy to understand and hard to argue with.

I have often also heard arguments that the incre

Answer 1

Expanding on "pjz" 's answer.

If you're getting a lot of INFORMATION(get* type of calls) based SOAP operations, currently there is no way you can cache them. But if you were to implement these same operations using REST, there is a possibility that the data(depends on your business context) can be cached, as mentioned above. Because SOAP uses POST for its operations, it cannot cache the information at the server side.

Answer 2

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

Therefor, its somewhat simplistic to try and compare the two, they are apples to oranges.

That said, a SOAP envelope (minus the data) is only a few k, so there shouldn't be any noticeable difference in speed provided you are retrieving a serialized object via both SOAP and REST.

Answer 3

The main impact in speed of SOAP vs. REST has not to do with wire speed, but with cachability. REST suggests using the web's semantics instead of trying to tunnel over it via XML, so RESTful web services are generally designed to correctly use cache headers, so they work well with the web's standard infrastructure like caching proxies and even local browser caches. Also, using the web's semantics means that things like ETags and automatic zip compression are well understood ways to increase efficiency.

..and now you say you want benchmarks. Well, with Google's help, I found one guy whose testing shows REST to be 4-6x faster than SOAP and another paper that also favors REST.

Answer 4

There are a few studies which have been done regarding this which you might find informative. Please see the following:

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

There is also an (somewhat out of date) interesting performance conversation about the topic at the MSDN Forums.

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

Answer 5

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

they both serve the same approach of communication abstraction by having stub objects you operate with and primitive/complex data types you get back without really knowing how this all is handled underneath.

I would always prefer (JSON-)RPC because

• it's lightweight
• there are many great implementations for all programming languages out there
• it's simple to learn/use/create
• it's fast (especially with JSON)

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

some more details you get from this stackoverflow question

Answer 6

SOAP and any other protocol which uses XML generally bloats 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 faster to serialise / deserialise - but don't use it exclusively for that reason. Do whatever you feel makes sense at the time and change it if it's a problem.

Anything which uses HTTP typically (Unless it's reusing a HTTP 1.1 keepalive connection, which many implementations do not) starts up a new TCP connection for each request; this is quite bad, especially over high latency links. HTTPS is much worse. If you have a lot of short requests from one sender to one receiver, think about how you can take this overhead out.

Using HTTP for any kind of RPC (whether SOAP or something else) is always going to incur that overhead. Other RPC protocols generally allow you to keep a connection open.