SOAP and REST can’t be compared directly, since the first is a protocol and the second is an architectural style. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn’t SOAP.
REST(REpresentational State Transfer)
REST is an architectural style. It doesn’t define so many standards like SOAP. REST is for exposing Public APIs(i.e. Facebook API, Google Maps API) over the internet to handle CRUD operations on data. REST is focused on accessing named resources through a single consistent interface.
SOAP(Simple Object Access Protocol)
SOAP brings its own protocol and focuses on exposing pieces of application logic (not data) as services. SOAP exposes operations. SOAP is focused on accessing named operations, each operation implement some business logic. Though SOAP is commonly referred to as web services this is misnomer. SOAP has a very little if anything to do with the Web. REST provides true Web services based on URIs and HTTP.
Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations.
A SOAP client works like a custom desktop application, tightly coupled to the server. There’s a rigid contract between client and server, and everything is expected to break if either side changes anything. The client needs previous knowledge on everything it will be using, or it won’t even begin the interaction. You need constant updates following any change, but it’s easier to ascertain if the contract is being followed.
I think these are the crucial points to understand what REST is about, and how it differs from SOAP:
- REST is protocol independent. It’s not coupled to HTTP. Pretty much like you can follow an ftp link on a website, a REST application can use any protocol for which there is a standardized URI scheme.
- REST is not a mapping of CRUD to HTTP methods. POST is the method used for any operation that isn’t standardised by HTTP, so it can be used for creation, but also can be used for updates, or anything else that isn’t already done by some other method. For instance, it’s wrong to use POST for retrieval, since you have GET standardised for that, but it’s fine to use POST for creating a resource when the client can’t use PUT for some reason. In the same way, PUT is not the “correct method for updating resource”. PUT is the method used to replace a resource completely, ignoring its current state. You can use PUT for creation if you have the whole representation the server expects, and you can use PUT for update if you provide a full representation, including the parts that you won’t change, but it’s not correct to use PUT for partial updates, because you’re asking for the server to consider the current state of the resource. PATCH is the method to do that.
- REST is as standardised as the parts you’re using. Security and authentication in HTTP are standardised, so that’s what you use when doing REST over HTTP. SOAP supports SSL just like REST additionally it also supports WS-Security which adds some enterprise security features. WS-Security offers protection from the creation of the message to its consumption.
- REST is not REST without hypermedia and HATEOAS. This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow. Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely. They are not only documenting something that’s supposed to be following the standard, but when you do that, you’re coupling the client to one particular moment in the evolution of the API, and any changes on the API have to be documented and applied, or it will break. If your clients are building URIs from templates in documentation and not getting links in the resource representations, that’s not REST. With the above in mind, you’ll realise that while REST might not be restricted to XML, to do it correctly with any other format you’ll have to design and standardise some format for your links. Hyperlinks are standard in XML, but not in JSON. There are draft standards for JSON, like HAL.
- Since REST uses standard HTTP it is much simpler in just about every way.
- REST is easier to implement, requires less bandwidth and resources.
- REST permits many different data formats where as SOAP only permits XML.
- REST allows better support for browser clients due to its support for JSON.
- REST has better performance and scalability. REST reads can be cached, SOAP based reads cannot be cached.
- If security is not a major concern and we have limited resources. Or we want to create an API that will be easily used by other developers publicly then we should go with REST.
- If we need Stateless CRUD operations then go with REST.
- REST is commonly used in social media, web chat, mobile services and Public APIs like Google Maps.
- SOAP is not very easy to implement and requires more bandwidth and resources.
- SOAP message request is processed slower as compared to REST and it does not use web caching mechanism.
- WS-Security: While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features.
- WS-AtomicTransaction: Need ACID Transactions over a service, you’re going to need SOAP.
- WS-ReliableMessaging: If your application needs Asynchronous processing and a guaranteed level of reliability and security. REST doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying.
- If the security is a major concern and the resources are not limited then we should use SOAP web services. Like if we are creating a web service for payment gateways, financial and telecommunication related work then we should go with SOAP as here high security is needed.
REST isn’t for everyone, and a proof of that is how most people solve their problems very well with the HTTP APIs they mistakenly called REST and never venture beyond that. REST is hard to do sometimes, especially in the beginning, but it pays over time with easier evolution on the server side, and client’s resilience to changes. If you need something done quickly and easily, don’t bother about getting REST right. It’s probably not what you’re looking for. If you need something that will have to stay online for years or even decades, then REST is for you.