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 increased overhead of SOAP may significantly impact used bandwidth and possibly even latency. I would like to see the results of a test that quantifies the impact. Any one know a good source for such information?

Solution 1

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.

Solution 2

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.

Solution 3

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.

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[Notre]

I think it's disingenous to say that REST doesn't define a message envelope; it says 'use what http uses', which is mime-types.

[Peter Ramos]

Oh really? I want to send a serialized C# class, how is the consumer of the REST protocol going to know how to parse it from a mime type.

[Darrel Miller]

I think the problem starts when you try and consider REST a protocol. REST is an architectural style that can use the HTTP protocol.

[Tim Cooper]

I interpret the question as using "REST" to refer to either (typically) "XML over HTTP" or (less commonly) "a customised format over HTTP", in which case a comparison is a valid question.

[MikeSchinkel]

@Tim Cooper - The man who coined the term REST would strongly disagree with that assertion, as well as most of the others who have helped spread the word about REST. [Read more on Wikipedia about REST](help promote) to hopefully understand why REST !== XML over HTTP.

[Chibueze Opata]

Great answer pjz, have you realized your answer does not have anything to say about XML-RPC or why it does not appear among the top choices to be considered.

[Fedearne]

Updated link for "one guy" learnosity.com/techblog/2008/03/cfmx-soap-vs-rest-benchmarks