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 standards-based protocol and was suited for long term business processes. Then came REST, which claimed to deal 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 APIs now are using REST-based web services.
The following tabulation examines the comparison between SOAP and REST APIs:
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 well-defined standards across security, messaging, and transport. Since it's 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.
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 the 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 of 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 light weight.
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.