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.

Solution 1

Performance is broad topic.

If you mean the load of the server, REST has a bit better performance because it bears minimal overhead on top of HTTP. Usually SOAP brings with it a stack of different (generated) handlers and parsers. Anyway, the performance difference itself is not that big, but RESTful service is more easy to scale up since you don't have any server side sessions.

If you mean the performance of the network (i.e. bandwidth), REST has much better performance. Basically, it's just HTTP. No overhead. So, if your service runs on top of HTTP anyway, you can't get much leaner than REST. Furthermore if you encode your representations in JSON (as opposed to XML), you'll save many more bytes.

In short, I would say 'yes', you'll be more performant with REST. Also, it (in my opinion) will make your interface easier to consume for your clients. So, not only your server becomes leaner but the client too.

However, couple of things to consider (since you asked 'what will you lose?'):

RESTful interfaces tend to be a bit more "chatty", so depending on your domain and how you design your resources, you may end up doing more HTTP requests.

SOAP has a very wide tool support. For example, consultants love it because they can use tools to define the interface and generate the wsdl file and developers love it because they can use another set of tools to generate all the networking code from that wsdl file. Moreover, XML as representation has schemas and validators, which in some cases may be a key issue. (JSON and REST do have similar stuff coming but the tool support is far behind)

Solution 2

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.

Solution 3

You phrase the question as if REST and SOAP were somehow interchangeable in an existing system. They are not.

When you use SOAP (a technology), you usually have a system that is defined in 'methods', since in effect you are dealing with RPC.

When you use REST (an architectural style, not a technology) then you are creating a system that is defined in terms of 'resources' and not at all in methods. There is no 1:1 mapping between SOAP and REST. The system architecture is fundamentally different.

Or are you merely talking about "RPC via URI", which often gets confused with REST?

Solution 4

I'm definitely not an expert when it comes to SOAP vs REST, but the only performance difference I know of is that SOAP has a lot of overhead when sending/receiving packets since it's XML based, requires a SOAP header, etc. REST uses the URL + querystring to make a request, and thus doesn't send that many kB over the wire.

I'm sure there are other ppl here on SO who can give you better and more detailed answers, but at least I tried ;)

Solution 5

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.

View more solutions

Comments

[Notre]

Is this a dup of stackoverflow.com/questions/106546/… ?

[Ivan_Bereziuk]

What you lose is the "over engineering" :-) aspects of SOAP. Encryption, Message signing, authentication, non-repudation, self describing services etc.etc. If you need to do any of this (and most services do not!) then go for SOAP.

[Darrel Miller]

I'm not convinced about REST interfaces being more chatty, but apart from that it is a solid answer.

[wuher]

I changed my nick from jedi to wuher (this answer refers to Jedi's answer, so that's actually wuher's answer now). Sorry for the confusion, I never should've picked the jedi nick in the first place..

[BentOnCoding]

If your application is designed with loose coupling then the web service implementations would be interchangeable.. your answer is kind of off topic and the assumptions you make about the interchangeability of a system you know nothing about are just wrong.

[stevenrcfox]

I dont think thats a fair comparison, developing a rest based sample that does the same thing as the soap example on wikipedia would be smaller over the wire than the wikipedia example.

[Darrel Miller]

@Overflow REST systems are required to make stateless, self-descriptive requests which causes information to be redundantly sent over the wire. SOAP systems can keep session state to prevent the need for re-sending certain information. Picking REST over SOAP based on message size is unwise.

[stevenrcfox]

@Darrell Miller It may be unwise to pick solely on message size, but if you're going to highlight issues, dont compare apples to oranges.

[Darrel Miller]

@Overflow I think my comparison of HTTP headers vs SOAP body is a far more valid one than trying to compare SOAP and REST. The original question was fundamentally flawed. I was just trying to provide a bit of practical perspective.

[stevenrcfox]

@DarrelMiller Your comparision of HTTP Headers vs SOAP body might be a valid one, if you compare it on the same data, doing the same thing. I'm not arguing the point of your answer, just that a good point made using a bad comparison/analogy reduces the value of the point.

[Shawn H]

This is an issue with service design and has nothing to do with the REST architectural pattern. I have seen SOAP services are equally as chatty. You can design nice REST-based services without resorting to long, complicated URL structures.

[peterh]

I guess the point I was trying to make was that I do not see REST as very elegant in the situations where the request is big and has a complex data structure. Those scenarios do exist but admittedly in most cases the data in the request is small and trivial and in such cases (which I believe is the majority of all cases) REST is an excellent choice, also when compared to SOAP. In REST world if the request is big then you have to embed the request data into the body to avoid the URL to become too long. And then what? Is that good for interoperability ?

[Adi Inbar]

I think this is a legitimate answer. Although it ends with a question seeking clarification, that doesn't invalidate it as an answer if for the most part it does attempt to answer the question with relevant factual information. And although it doesn't address per se the issue of performance, it addresses the validity of the question's underlying premise, which is relevant to providing a complete answer to the question. (Whether it's right or wrong is a separate matter, which is better addressed by up/down votes than delete votes.)

[MariuszS]

Json is slower than XML

[serg.nechaev]

To really answer the question you need to address specific use-cases and specific library implementations. This answer makes too many assumptions, starting with sessions, "chattiness" and "easier for customers".

[serg.nechaev]

It can be slower and it can be faster, they are both data in text format in the end.

[Oooogi]

RESTful service can have server side sessions. It is usually implemented via cookies or custom http headers.