One of the most debatable topics when building communication channel between service components is whether to use SOAP or REST. Let’s first understand what each one of them are:
SOAP (or Simple Object Access Protocol) is a protocol that was designed to ensure that applications built on different platforms and in different programming languages can exchange data easily.
REST on the other hand is an architectural pattern. A service component that follows REST principles is called a Restful service. A Restful service uses the normal HTTP verbs of GET, POST, PUT and DELETE when working with the required components.
Since REST is an architecture, REST defines following architectural constraints:
- Uniform Interface
A resource in the REST world, should have only one logical URI (or uniform resource identifier) that should provide a way to fetch information related to the resource. The resource URI should follow a consistent pattern, so that once a client becomes familiar with APIs of one the resource, it should be able to use similar approach for other APIs as well.
In the REST world, it essentially means that the client and server can scale/evolve independently without dependency on each other as long as the API interface is kept same.
RESTful services are stateless meaning server will not store anything about the last HTTP request client made. It will treat each request as new. When interacting with a RESTful service, a client has to be responsible for managing the state of the application.
In REST, caching can be applied to resources whenever neccessary, and the resources have to declare themselves as cacheable. Caching helps bringing down the number of trips made to server bringing performance improvement to the client.
- Layered System
REST allows us to have a layered architecture. For instance the APIs can be served from Service A, authentication done from Service B, and data stored in Service C. This way REST provides a facade of Service A to client, abstracting the client from downstream dependencies.
When to use REST over SOAP?
REST stands outs over SOAP in following cases:
- Limited bandwidth
SOAP messages being heavier in content, requires a lot o bandwidth and should be avoided, if network bandwidth is a constraint, for example: an application on a mobile that is using a 2G/3G network will experience higher latency and slow performance when interacting with Server via SOAP protocol. In such cases, REST should be preferred.
If there is no requirement to maintain state from one request to another, REST should be used.
If there is a need to cache a lot of requests, REST comes handy. This is because a SOAP request is sent via HTTP POST when using HTTP protocol. Since POST requests are non idempotent in general, it is not cached at the HTTP level. REST can be cached provided that the requests are idempotent (GET, PUT, DELETE). POST requests still won’t be cached.
When to use SOAP over REST?
SOAP should be used in following cases:
- Stateful operations
SOAP has built-in stateful operations. REST is naturally stateless, but SOAP is designed to support conversational state management.
- Formal Contracts
SOAP is good for applications that require formal contracts between the API and consumer since it can enforce the use of formal contracts by using WSDL (Web Services Description Language).
- Async processing and reliability
If there is a requirement that the client needs a guaranteed level of reliability and security then the new SOAP standard of SOAP 1.2 provides a lot of additional features, especially when it comes to security.
At the end of the day, there is no one clear winner but the best protocol is the one that fits the requirements, supports the the types of clients that are needed, and what is needed in terms of flexibility.