This article aims to help you understand REST and gRPC , the differences between them and its suitability for your use case.
What is API ?
API is an acronym for Application Programming Interface, It allows two applications to communicate with each other. The communication can be via sharing data, posting a trigger to get the job done. It can be used for any purpose, and basically provides a platform for exchange of data. The API can be implemented in different styles, we will explore REST and gRPC ways in this article.
What is REST ?
REST is an acronym for Representational State Transfer. It is also commonly referred to as the RESTful API. There are several formats in REST through which the information can be delivered. JSON (Javascript Object Notation), HTML, XLT, Python, PHP, or plain text. Among this most commonly used format is JSON. This exchange of information happens via HTTP. It conforms to the client-server architecture where requests are managed through HTTP.
What is gRPC ?
gRPC is an acronym for Google Remote Procedure Call. It uses HTTP/2 protocol , however HTTP is not exposed to the API designer. The information is delivered using protobufs. The client here uses gRPC by having to decide which procedure to call and also uses the code generated stub to make a call and passes the expected parameter values. The client application communicates with the server on a different machine by directly making a method call like it were a local object. In a bidirectional streaming RPC, the call is initiated by the client invoking the method and the server receiving the client metadata, method name, and deadline. The server can choose to send back its initial metadata or wait for the client to start streaming messages. Client and server-side stream processing is application specific. Since the two streams are independent, the client and server can read and write messages in any order.
Example of a use case, where REST model will be suitable for :
REST APIs are very effective at creating modular components for a server-based piece of software and sharing them with the world. It is suitable for services developed and maintained independently like the web itself. The client and server are loosely coupled and can change without breaking each other.In an example if we are designing a dashboard to accept the data from the customer through the browser and calculate a bureau score. In this use case , the backend micro services may have to talk to a third party for fetching the bureau data. This scenario, the ideal way of implementing API in a RESTful way would be advantageous.
Example of a use case, where gRPC model will be suitable for :
gRPC APIs on the other hand, are the best option for developers who need to be able to deliver a stream of requests while working on a backend project which is an app used for Collections , considering a financial system use case. Say this collection app is meant to update the system with the incoming payments from various customers through a collection agency. In this use case we will have to deal with high volumes of payment transactions. Basically it’s a mobile application backed with microservices backend, whose availability and performance is much more important considering the scale.
Points for Comparison :
| Features | REST | gRPC |
| Format of the Payload | Json and XML formats are commonly used. Allows other formats also, no restriction in the Payload formats. | Accepts and returns Protobuf messages (data binary). |
| Service contract | Serialised, doesn’t mandate any structure for exchanged payload , In case the response is a JSON, it needs to be serialised. | Stream typed messages which automatically converts from their Protobuf representation to your programming language. |
| API Contract | Is often loose and optional. | Is strict and requires it to be defined in the proto file. |
| HTTP Protocol | Usually built on a HTTP 1.1 model, but also available on HTTP/2, but this does not use the complete bidirectional and streaming capability. | Uses HTTP/2 and takes complete advantage by providing bi-directional communication. |
| Conceptual Model | Embraces its features and concepts which are built very tightly on top of HTTP. | gRPC model translates directly using the concepts of Programming like interfaces, data structures and function methods. |
| Streaming Model | Allows Request- Response model which is mainly built on HTTP 1.x. | Allows streaming – server side, client-side and bi-directional streaming – duplex streaming model. |
| Code Generation Tool | Uses third party tools like Swagger, Postman etc to auto generate the Code for API calls. | Code generation features are native to gRPC via its protoc compiler. |
| Speed of Message Transmission | Message transmission speed is comparatively slow. | Message transmission is 7 to 10 times faster than REST. |
| Speed of Implementation | Faster implementation using a REST API, approximately 10 minutes required to implement a simple REST API. | Implementation is slow, approximately 45 minutes required to set up a simple gRPC service. |
| Browser Support | Fully supported by all browsers. | Is limited and requires a gRPC-web with a proxy layer to convert between HTTP/1 and HTTP/2. |
Conclusion
Developers who find themselves in a dilemma to choose between gRPC and REST, and why does that matter should perk up. Although the decision making is tough, you don’t have to be confused at all.
REST is a classic API framework, and still offers its reliable benefits of uniformity and ease of use. gRPC is also a great choice, especially if there’s a need to implement streaming requests, which is hard to do in REST, or a desire to move away from JSON packets to Google’s language-neutral “protocol buffer” data structures.
The bottom line is that both types of API offer benefits and are brilliant in its own space, rather than questioning “REST vs gRPC”, one must explore the benefits both the API styles have to offer and try out using the blend of both to satisfy different needs.
