The full article is available on TechBullion - read it here.

If you head up a development team, then choosing which architectural style to use is a critical decision to make when building up an IT infrastructure. APIs remain an important part of this decision making process; they are mediators through which information is sourced and transferred. If you want to interact with another computer or software system to retrieve information or perform a function, an API helps you communicate with that system so it can understand and fulfil the request.

REST: the gold standard for web APIs

For years, REST (Representational State Transfer) has been the gold standard for building web APIs, and is a set of principles that dictate how a web service should behave and interact with clients. With them, developers can quickly set up a web server that can then share information with every web browser that connects to it. REST is simple and easy to use, requiring less coding than its counterparts. This simplicity and scalability means it can accommodate large volumes of request, and so it is often deployed horizontally across applications in order to reduce network traffic and improve performance. REST APIs are also frequently used in other places such as mobile applications and microservices. 

This simplicity does come at a cost though; although REST is a well-defined architectural style, there are no standardised rules for its implementation. This can lead to inconsistency and unpredictability in how different APIs are designed and implemented. REST also communicates via HTTP request-response cycles, which are not designed for real-time interactions and can carry significant overhead costs due to the large amounts of data that need to be transferred. 

gRPC has entered the chat

Developed by Google and released to the public in 2015, gRPC is an open-source remote procedure call (RPC) framework that enables clients and servers to communicate with each other transparently and efficiently. While REST is more akin to sending a letter and then getting a response with a letter, the flow of gRPC is more like having a phone conversation; the exchange of information is both continuous and instantaneous. With gRPC, one program can send a message to another program, and they can have a back-and-forth conversation, called a “stream,” without having to wait for each message to be sent and received separately.

The full article is available on TechBullion - read it here.