Rest vs. Soap. Has REST a better performance?

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开发者_如何学Go 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.

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)

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.

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?

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

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.

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.

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.

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)

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.