31

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.

user229044
  • 232,980
  • 40
  • 330
  • 338
Luixv
  • 8,590
  • 21
  • 84
  • 121
  • Is this a dup of http://stackoverflow.com/questions/106546/performance-of-soap-vs-xml-rpc-or-rest/ ? – pjz Dec 03 '12 at 18:06
  • 1
    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. – James Anderson Jan 09 '18 at 18:09

9 Answers9

48

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)

wuher
  • 1,629
  • 15
  • 12
  • 6
    I'm not convinced about REST interfaces being more chatty, but apart from that it is a solid answer. – Darrel Miller Nov 12 '10 at 12:35
  • 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 Oct 23 '14 at 07:14
  • RESTful service can have server side sessions. It is usually implemented via cookies or custom http headers. – Oooogi Dec 31 '15 at 09:45
14

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.

James Anderson
  • 27,109
  • 7
  • 50
  • 78
12

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?

jbrendel
  • 2,390
  • 3
  • 18
  • 18
  • 6
    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. – BentOnCoding Jul 05 '11 at 21:58
  • 3
    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.) – Adi Inbar May 23 '14 at 18:13
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.

Shawn H
  • 1,227
  • 1
  • 12
  • 18
5

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 ;)

KBoek
  • 5,794
  • 5
  • 32
  • 49
4

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.

peterh
  • 18,404
  • 12
  • 87
  • 115
  • 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. – Shawn H Oct 22 '12 at 15:29
  • 1
    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 ? – peterh Oct 30 '12 at 12:43
4

Just to add a little to wuher's answer.

Http Header bytes when requesting this page using the Chrome web browser: 761
Bytes required for the sample soap message in wikipedia article: 299

My conclusion: It is not the size of bytes on the wire that allows REST to perform well.

It is highly unlikely that simply converting a SOAP service over to REST is going to gain any significant performance benefits. The advantage REST has is that if you follow the constraints then you can take advantage of the mechanisms that HTTP provides for producing scalable systems. Caching and partitioning are the tools in your toolbelt.

hlscalon
  • 7,304
  • 4
  • 33
  • 40
Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • 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.. – wuher Mar 22 '11 at 19:30
  • 1
    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. – stevenrcfox Oct 26 '11 at 11:33
  • @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. – Darrel Miller Oct 26 '11 at 12:22
  • @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. – stevenrcfox Nov 02 '11 at 16:43
  • @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. – Darrel Miller Nov 02 '11 at 18:35
  • @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. – stevenrcfox Nov 04 '11 at 13:28
1

In general, a REST based Web service is preferred due to its simplicity, performance, scalability, and support for multiple data formats. SOAP is favored where service requires comprehensive support for security and transactional reliability.

The answer really depends on the functional and non-functional requirements. Asking the questions listed below will help you choose.

REf: http://java-success.blogspot.ca/2012/02/java-web-services-interview-questions.html

Does the service expose data or business logic? (REST is a better choice for exposing data, SOAP WS might be a better choice for logic). Do the consumers and the service providers require a formal contract? (SOAP has a formal contract via WSDL) Do we need to support multiple data formats? Do we need to make AJAX calls? (REST can use the XMLHttpRequest) Is the call synchronous or asynchronous? Is the call stateful or stateless? (REST is suited for statless CRUD operations) What level of security is required? (SOAP WS has better support for security) What level of transaction support is required? (SOAP WS has better support for transaction management) Do we have limited band width? (SOAP is more verbose) What’s best for the developers who will build clients for the service? (REST is easier to implement, test, and maintain)

Sampath Kumar Madala
  • 163
  • 10
0

You don't have to make the choice, modern frameworks allow you to expose data in those formats with a minimum change. Follow your business requirements and load-test the specific implementation to understand the throughput, there is no correct answer to this question without correct load test of a specific system.

serg.nechaev
  • 1,323
  • 19
  • 26