Generally, in technology, we face the dilemma of choosing between two or more services. It is a similar situation when we want to access web services. If we have to make a choice between SOAP and ReST APIs, we certainly get torn between the two options. On the face of things, it is an investment, as usual, we need to be mindful about.
SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are two kinds of Web services that have been around for a while. SOAP was more of a standard-based protocol and was suited for long term business processes. Then came REST which claimed to contend the issues with SOAP. It offered a higher degree of flexibility than SOAP and in certain conditions, it provided simple methods to access web services. Both of them relied on a well-established set of rules that were considered as standards in the interest of data exchange.
70% of all new API now are using ReST based web services
Following tabulation examines the comparison between SOAP and REST APIs
|
SOAP |
ReST |
|
SOAP is a “Simple Object Access Protocol” and has standards specified |
ReST is not protocol, rather a way of calling Web calls over HTTP using XML or JSON |
|
The packaging defines
|
ReST by default is stateless.
|
|
A call state can be maintained across multiple calls. |
Normally these are stateless (but you could manage states if you like) |
|
It has a well-defined standard across Security, messaging and transport. Since it is over HTTP, all security features like SSL are part of it. |
OAuth and Basic Auth most commonly used for security authentication. Other standards not as well defined. Builds on top of HTTP protocol – GET, POST, DELETE, etc. Transport security is usually SSL. |
|
Often you might face issues around cross Language import as it might work with .NET but not with Java or Salesforce Apex |
Easy to use as its simple HTTP protocol with JSON or XML structures in getting and post. Great for using with Javascript, AJAX, and jQuery. |
|
SOAP utilizes greater bandwidth to communicate metadata |
REST uses comparatively lesser bandwidth. |
|
Has standards around error handling |
Error handling and response are decided by the developer of the API |
|
It requires less plumbing code for developers to code in application layer as there are many tools to convert the “Web Services Definition Language” aka wsdl (an XML) file into code in many programming languages |
It requires comparatively more plumbing code in terms of transaction, security, and coordination. If you have YAML, RAML or Swagger, then you can use tools to automatically create code for many programming languages including those for mobile devices. |
|
It has comparatively slower operating speed due to overhead of running a SOAP WebService container |
Usually, ReST offers rapid operating speed without the need for extensive processing. |
|
Examples: Paypal SOAP API, Salesforce SOAP API |
Examples: Youtube API, Twitter API, Pinterest API, LinkedIn API |
As most IT Architects continue to debate, While ReST and SOAP both have a place, ReST continues to have wider adoption, mainly because of its ease of use and it being lightweight.
We are seeing a growing trend in API Management, and we see ReST take a lead. Most of them support one of YAML, RAML or Swagger definitions making it easier to learn, try and implement them.
Hope it helps you understand on a fairly high level. Do give your comments to expand this blog below.
Greg Brown
Hi Rajeev,
Here is another alternative for building web services:
https://github.com/gk-brown/HTTP-RPC
It combines the flexibility of SOAP (i.e. custom verbs) with the simplicity of REST (stateless interaction and human-readable URLs/JSON). The project currently provides support for implementing HTTP-RPC services in Java, and consuming services in Java, Objective-C/Swift, and JavaScript.
Greg