SOAP vs REST has been quite an issue for some time now. And now with Graphql gaining popularity, people have started to converse about REST vs GraphQL. In this article, we will do a comparison of SOAP vs REST and REST vs GraphQL. We will see the advantages and disadvantages of all three and when to choose what.
SOAP vs REST
About SOAP:
SOAP stands for Simple Object Access Protocol. It is basically a messaging protocol that was developed by Microsoft. It relies on XML heavily and defines a very strongly typed messaging framework. It is used for data exchange in a distributed environment. SOAP works with any of the application-level protocols like HTTP, TCP, SMTP, etc. The data which is returned is always in XML format. The structure of the XML of the request and response are explicitly defined. All of the SOAP specifications and definitions are developed and maintained by W3C (World Wide Web Consortium). SOAP has strict rules and built-in comprehensive features in the form of security, transactions, and ACID (Atomicity, Consistency, Isolation ad Durability). For all these the complexity is higher and it requires more bandwidth and resources for processing.
This is the XML structure of a SOAP response message from w3.org.
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pick up Mary at school at 2pm</m:msg> </m:alert> </env:Body> </env:Envelope>
- Envelop: It is the starting and ending tag of the whole message
- Header: It contains optional attributes, like meta-data, expiration date,etc.
- Body: It contains the actual response data that is to be sent
Advantages:
- SOAP has built-in security and error handling
- Successful/Retry logic for message functionality
- SOAP is transport-independent (can work with HTTP or TCP or UDP or SMTP)
- SOAP has built-in ACID compliance
- SOAP relies mainly on XML. XML parsing is a heavy operation
- It consumes more bandwidth and requires more computing power.
About REST:
Below is a sample REST API response. This is one of Github's public API
Advantages:
- REST is light-weight, flexible and scalable
- REST supports all data types be it XML, JSON or TXT
- REST APIs use a single uniform interface
- In terms of design, REST is much closer to other web technologies
Disadvantages:
- REST does not have any in-built features for security and error handling
- REST is not suitable for distributed environments
| SOAP | REST | |
|---|---|---|
| Design | It is a standardized protocol with well-defined rules | It is an architectural style with certain constraints |
| Functionality | Function-driven (Data available through functional services) | Data-Driven (Data available as a resource) |
| Data Format | XML | XML, JSON, TXT, etc. |
| Caching | Cannot be cached | Caching available |
| Security | It has WS-Security with SSL support | SSL support and HTTPS |
| Performance | Requires more bandwidth and resources | It is lightweight and requires fewer resources |
| Transfer Protocol(s) | HTTP, TCP, UDP or SMTP | HTTP |
| ACID Compliance | Has in-built ACID Compliance | Does not have ACID compliance |
REST Vs GraphQL
In the previous section we discussed about REST in detail, so now lets focus on GraphQL.
About GraphQL:
GraphQL is a relatively new technology that has made a lot of buzz. It is a modern way of developing and querying APIs. GraphQL is developed and maintained by Facebook which made its stable release in 2018. GraphQL was developed to overcome some of the shortcomings of REST.
One thing about REST is that we end up creating multiple endpoints to fetch data that are structurally different but are relatable. Sometimes we end up over-fetching or under-fetching the data. Let us understand this by an example.
Here, we will have a look at GitHub's public API V3.
One end-point is
GET /search/users?q=John. This end-point returns us a list of users with a unique username attribute for each user with the name 'John'. Now suppose we want to get the repositories of that user. For that, there is another end-point GET /users/:username/repos. So, here we have two different end-points. Also, like for the first end-point we will get all the attributes of that user like name, email, location along with the username. But we were interested in getting only username. So this is kind of over-fetch.With GraphQL the client is able to fetch all the required information with a single call, rather to make multiple REST requests to fetch the same. While requesting the client can specify the data he wants and GraphQL will return only that data. Also, there is only one end-point. The GraphQL server will first check the data the client has specifically requested for and then query it out accordingly.
See this example:{
query getUserAndRepo{
getUser(name: "John"){
username
repos(){
id
title
}
}
}
}In GraphQL, with such similar query we can get the id and title of repositories of the user named "John". This can be achieved with a single call, also there will be no data over-fetch or under-fetch.
Now, all these doesn't mean that REST will become obsolete and GraphQL will be used everywhere. We should keep in mind that whenever any new technology comes up it too has its own pros and cons.
Advantages:
- GraphQL allows us Declarative Data fetching, i.e client can specify the data it needs along with specific entities and attributes
- No data over-fetching or under-fetching in GraphQL
- GraphQL is a strongly typed query language. Being strongly typed, it is less error prone
- GraphQL is version free, the structure of the response data is determined entirely by the clients query. Any change/modification on server code does not affect the structure of the response data
Disadvantages:
- A GraphQL query can face performance issues if a client asks for too many fields at once
- GraphQL cannot cache response data. To implement caching certain libraries like Apollo-Client are required
| REST | GraphQL | |
|---|---|---|
| Type | It is an architectural style with certain constraints | It is a specification, which can be implemented by a language |
| Endpoint | Multiple endpoints for multiple resources | Only a single endpoint |
| HTTP Methods | GET, POST, PUT and DELETE all can be used | Only POST is used here |
| Caching | Caching available | Normally not available. Can be made available via libraries on top |
| Data Fetching | Specific Data on a single API call | Fixed Data with multiple API calls |
Where to use what?
The answer to this question is based on what use-case do you have. All SOAP , REST and GraphQL have its pros and cons.
SOAP is mostly used for enterprise level application which require high security and complex transactions are involved. API for payment gateways, financial applications, CRM applications, etc. mostly use SOAP.
REST on the other hand provides point to point communication. Most public APIs provided by organizations are REST APIs. When flexibility and scalability is desired then REST API is a good choice.
GraphQL as we mentioned makes querying simpler and helps the client to get the data as per its needs. But GraphQL does not give any significant advantage over REST performance wise, unless the application is executing like a millions of queries per second.
Hope after reading this article you get a clear picture on the difference between SOAP, REST and GraphQL and also get a understanding about the pros and cons of each of them. Do mention your thoughts in the comments. If you like it do subscribe for more articles on software development stuffs. Also, I'd like to grow my readership, if you enjoyed this article, share it with a friend! Stay safe and Happy Coding!
0 Comments