Today I was asked to describe the difference between SOAP and REST web services and how to decide which one to use? Here is what I came up with:
- SOAP web services support RPC-Style and Message oriented style while REST is only RPC-Style.
- REST is closely tied to HTTP while SOAP is transport independent and can be used with HTTP, Messaging, e-mail, UDP, etc.
- SOAP is XML oriented while REST allows multiple data formats like XML, JSON, HTML, text etc.
- REST reads can be easily cached thus performing better and scales easily. Also SOAP is more chatty thus using more bandwidth.
- On the security side, WS-security allows for a SOAP message to identify the caller, sign the message, and encrypt message contents. This allows SOAP message to be secure even when using non-secure transport like e-mail. Security in REST is only SSL using HTTPS transport.
- SOAP supports more complete transaction management using WS-AtomicTransaction.
- SOAP provides standard WS-ReliableMessaging framework while REST does not have any messaging framework and client is expected to recover from communication failures.
So how do you go about deciding which one to use? I guess it depends on your requirements. Most internet applications don’t require the level of security or transaction support offered by SOAP, so REST is preferred because it is easier to implement, test, and maintain. REST is also a better choice if you are just exposing data because of its support for multiple data formats. On the other hand, if you require complex security, transport independence, reliable message delivery, and distributed transaction support then SOAP is the better candidate.
Please feel free to leave comments if you think I have missed something.
Great summary, I always end up sending lots of links to people who ask me this question, this sums most of it.
Definitely religious!
A couple more points
* SOAP makes it easy to generate native clients from a WSDL. REST requires you to write a client library for all platforms you wish to support. Or expect your users/integrators to do it for you.
* The multiple data formats makes REST more suitable for client-server use. For example, you can use AMF binary for Flash clients, or JSON for JavaScript clients. Both Flash and JavaScript engines are extremely slow at processing XML (SOAP).
* SOAP is a more RPC style, whereas REST is more resource oriented. REST works nicely with CRUD operations.
I tend to use REST for client-server, and SOAP for backend system to system integration.
I find it easier to document your soap service. The best things I could find for rest are SMD for your service description and JSON schema (if you use JSON). So iI guess everybody tries to use REST today,but a unified documentation method like soap protocol and XML schema are missing
I like JSON Schema pretty well, wish it were more widespread.
JSON-RPC is pretty well defined for a lot of those cases one might normally turn to SOAP.
Just an observation, REST is a concept and its current implementation support is limited to HTTP. This does not mean at a later point in time it cannot be applied to other transmission protocols.
@Stuart There is something called WADL for RESTful services. Which acts similar to WSDL (I haven’t tried generating or don’t know about tools)
@Tariq Can you elaborate how u came to conclusion that REST is only RPC-style ? To me, it addresses more like resource rather then Procedure..