Is RESTful faster than SOAP? and when to use one of them?

Question

Duplicate: This is a duplicate of \"What are the best uses of REST services?\" and many others. Please close it.

In web development:

Should

Answer 1

My client (major carrier) actually ran a performance test on REST vs SOAP access to their API's and found the difference was almost non-existent. XML parsers are pretty quick these days and aside from that, there isn't much actual overhead when using SOAP. The contract (WSDL) with all it's rules and specifications is something that comes into play when a client program is being written or updated, not so much in the scope of a real-time exchange with an API.

Answer 2

One factor is that RPC communications are often not cached as part of the HTTP stack because the caching middleware shouldn't need to understand the contents of the request. So, RESTful systems can take better advantage of caching.

Answer 3

In my experience, SOAP adds some overhead that you can avoid by making a RESTful service. That being said, in your decision, you should consider your audience. If you are expecting to have a large variety of outside-world consumers of your service, I would recommend SOAP, because there are a lot of tools that automatically generate a programmatic interface to it.

Some web services, like PayPal, offer multiple alternatives, so you could also consider choosing both.

Answer 4

REST will almost always be faster since there's less processing and smaller envelopes.

Answer 5

REST should be faster than SOAP in most cases since it is more light weight, less overhead.

But there are some situations in which you need the functionality that is in that overhead.

Unless you want to standardise on one (this reduces the number of technologies in your solution, and therefore the complexity), the rule of thumb would be use REST when you can and SOAP where you must.

Answer 6

To directly answer your question, I'd say yes. REST is usually regarded as the lighter alternative. Also, at the current stage, REST is still consider/practiced by many to be more of a "direction/guideline" then a full protocol.

There's an interesting article depicting their differences in an interesting dialogue.

Personally, I'd say REST should be pretty much better than SOAP in all cases a normal person would choose. On the other hand, designing a true REST architecture requires a lot of planning and considerations. Most attempts fail at that and become STREST (mentioned in the above article), which is like mixing SOAP and REST and losing some of the benefits REST provides.