Modern and Legacy API Architectures
Tags: architecture, graphql, grpc, api
Published: 2019-07-30 17:46:44

Let's talk about how we have been architecting our APIs and how far we have come forward. There have been only SOAP and ReST architectures leading the industry. Now after all these years we have gRPC, graphQL and more to choose from. 

> More power comes with more responsibility

There are advantages and disadvantages of using new architectures. So you need to figure it out yourself about which one fits your project requirements.

**SOAP:**
SOAP is known as the Simple Object Access Protocol. In other words, SOAP is a protocol that defines how internet services communicate with one another or interact with apps that invoke them. SOAP is an XML-based protocol for accessing web services over HTTP. It has been designed to operate with XML over HTTP and has some kind of specification that can be used for every application. Web applications designed in Java and .net uses SOAP architecture.


  ![Advantages and disadvantages of using SOAP architecture](https://lh4.googleusercontent.com/SDQO6AJaSBP-Z8BbrrUbhRa8Tlaaj1OfLqvSosrPgE_Fo3IhEtZpkLMAZmtm3zYTCMdWDlzNt5ImSg=w1366-h657)

**ReST:**
Also known as ReSTful web service. It provides some excellent features, including stateless servers and access to resources. 

> As per the REST (REpresentational “State” Transfer) architecture, the server does not store any state about the client session on the server-side. This restriction is called Statelessness.

In addition, it comes with different types of methods that you send a request to the server like get, post, delete, put. These methods are used to perform actions like Create, Retrieve, Update, Delete. Furthermore, RESTful allows numerous formats of data, while SOAP allows the only XML.

  ![Advantages and disadvantages of using ReST architecture](https://lh6.googleusercontent.com/b-QteMYBOgofx0fUDgygIXfYmP_HgB_82xUFNMgjWv7duENbdXML_IHg8AtIyYbP9nK9fROU7gP45A=w1366-h657)

**GraphQL:**
It's is developed by Facebook and released publicly in 2015. It's strongly typed query language to define both the requests and the responses, giving application more control over what data it needs from an API. It has been designed to meet the need for greater flexibility and efficiency. Many large businesses like Spotify, Facebook, GitHub, NYTimes, Netflix, Walmart are using it. 


  ![Advantages and disadvantages of using GraphQL architecture](https://lh5.googleusercontent.com/d4ktkca8hFwHoayD-H-HWm9ykY3KBZbUjoLCBC9DuGAOBXlan79ILqqk-TCgbY9j4E7MFGXAuiSKsQ=w1366-h657)

**ReST vs GraphQL**
Let's say I have a list of products with some Information of product on each Index and we want to show this list on mobile and web with both having completely different UIs and we don't want to get extra data from API. With ReST, It's not possible using single API we need to create another API for either web or mobile 

![ReSt Web vs Mobile](https://lh3.googleusercontent.com/WHSl0dOLYBxMFP0ECRpoG5Mntn3pGx-l1vndoe6xUrfg6wDBdzRflb1Aaxp408mNGpVyx4-MjywUkw=w1366-h657)

but dealing with this type of scenario can easily be handled using graphQL.

![graphQL Web vs Mobile](https://lh3.googleusercontent.com/8vpFB-lqjJTgsLpe4L9qV8JB_yaBypvjIMiGOdhb0iChAOAU4h5uw1vjf1GfuUlfHslW6LG0KeqMpw=w1366-h657)



**GRPC**:
GRPC is a recursive acronym which means, gRPC Remote Procedure Call. RPC is a protocol that can be used by a program to request a service from a program on a different computer without the need to understand the details of the network. GRPC is a Google-based RPC platform that was announced and open source at the end of February 2015. The framework is based on a client-server model of remote procedure calls. 
The RPC functionality is that a sender or client creates a request for a remote server that translates and sends RPC in the form of a procedure, function or procedure call. If the distant server gets the request, the application returns its reply to the customer and proceeds with it.

  ![Advantages and disadvantages of using GRPC architecture](https://lh4.googleusercontent.com/JgMjXcclx6ufsZgpuGboWG_MMn5AB1avJBmeb7W0zUc7_SQswggivMxucqLW3Q3mazkLIXQNXNK0nA=w1366-h657)



**Conclusion**
Finally, we wish to conclude that there is no general solution for selecting protocols for architecting our APIs. Each application is unique and you should make your decision on the best for your project. In addition, to achieve the optimum results, you can combine architecture.