Comparing REST and SOAP, which one should you use?

For this week blog post, I will write about the basic and differences between REST APIs and SOAP. Some people would say one is better than another, but that statement, for me I think, is incorrect because each protocol does have its own advantages to make use of and of course, there would also be a lot of annoying disadvantages that we all have to deal with. For this blog, I will have my information based on this article.

Firstly, I would go through a quick overview for both protocol. For stater, they both provide an answer to a same question, that is how to access to web services. SOAP stands for Simple Object Access Protocol. It has been around for a while and originally designed by Microsoft. While Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (COBRA), which are old technologies, fail because it rely on binary messaging, SOAP is designed to replace them as it works better over the internet. SOAP was initially released and submitted to Internet Engineering Task Force (IETF) and they standardize it. So how does SOAP works? SOAP heavily relies on XML to provide messaging services. It is also designed to support expansion and they have an abbreviation associated to their name such as WS-Addressing, WS-Policy, WS-Security, etc. and you can find out about these standards here. The reason to use SOAP is because it is highly extensible. For example, if you have a web service that you would like everyone to have access to it, then there is no need for WS-Security, but in case you change your mind, you can always add in to your service.

Let's look at REST APIs. REST or Representational State Transfer is somewhat simpler to use and also known as a lightweight alternative. Instead of having just XML, REST APIs usually relies on the URL and sometimes Javascript Object Notation (JSON), XML, EDN or some other type of body is required. REST can use four different HTTP 1.1 verbs, GET, PUT, POST and DELETE to perform a single task. Unlike SOAP, REST doesn't use XML to provide the response, it can have the data returned as Command Separated Value (CSV), JSON or Really Simple Syndication (RSS). The point of REST is not just because it is lightweight, but also because it returns the data in a form that can easily parsed within the language that you are using.

There are a lot of reasons to put one over another, it depends on how you see it and also depends on what your project is about. It is actually really hard to choose between these two, so I will compare them and let you decide.

Consider the using SOAP over REST, SOAP does have the feature that allow user to use without using HTTP or in another word, it has the language, platform and transport independence. You can read more about using SOAP with Simple Mail Transfer Protocol here. Another point to consider is that SOAP works well with distributed enterprise environment, which REST always assume it is going to be just point-to-point communication. SOAP does have to potential for extensibility, it is standardized along with a built-in error handling and it has the automation when using certain language products. 

How about REST, after disadvantages about it, should you still use it? The answer is absolutely because it does not required expensive tools to interact with the web service. Moreover, it has much smaller learning curve to go through, so if you are new to the field, you might want to consider having this on your project. I did point out that while SOAP is using XML that makes it so complicated, REST makes it more simple to just return a form that can easily parsed by most language, which simpler and decrease the time of the development process.

Overall, I think both are very powerful protocol for developer to make use of. It is true that sometimes you should consider one over another, but to understand that each protocol has definite advantages and equally problematic disadvantages is very important. I think it is amazing that we were given two choices to fit our project needs.


Popular posts from this blog

Path testing

Software Quality Assurance Introduction

Reflect as you work