Introduction

Building efficient and reliable communication between applications is a crucial part of the modern world of software development. API or Application programming interface acts as an intermediatory that defines a set of rules to help different apps communicate with each other seamlessly. API facilitates the exchange of data between systems ensuring data consistency and security measures.

Imagine you are a customer sitting at a table in a restaurant. You need to communicate with the kitchen to order food. However, you don't have direct access to the kitchen and the chef doesn't know what you want unless you tell it to a waiter. The waiter acts as an intermediatory or bridge between the customer and the kitchen. The waiter understands your order, communicates with the kitchen, and also delivers the food back to your table.

In this analogy, the restaurant is like a system, and customers and chefs are the applications. The waiter acts as the API.

REST

REST (Representational state transfer) is an architectural style that was developed to provide guidance for building the architecture of the World Wide Web. REST doesn't necessarily use HTTP. We can use other transfer protocols, such as FTP, SMTP, etc. and your API can still be RESTful. Typically HTTP 1.1 Protocol is used with RESTful web API for communication between client and server. REST was initially developed to manage communication on a complex network like the Internet. REST API transmits data in JSON or XML format using some HTTP methods eg. POST, GET, PUT, PATCH, DELETE etc.

gRPC

gRPC (Google Remote Procedure Call) is a modern open source high-performance Remote Procedure Call (RPC) framework developed by Google. Google has been using Remote Procedure Call (RPC) infrastructure called Stubby to handle communications in large-scale distributed applications since 2001. After years of internal use, Google decided to further enhance and improve the technology and launched the next generation of Stubby, which they named gRPC. It follows an RPC implementation that uses HTTP 2.0 protocol. It also uses Protocol Buffer, an open-source mechanism for serializing the data in a structured format. It describes the service interface and the payload message. Here is an example of protocol buffer message:

Comparing REST and gRPC

HTTP 1.1 vs HTTP 2.0

1. Multiplexing: In HTTP 1.1, it sends data one after another. Hence if one resource cannot be loaded, then it will block all other resources. In HTTP 2.0, it opens up a single TCP connection and can send multiple streams of data at once so that no resources are blocked.

2. Client Server Architecture: HTTP 1.1 only supports unary communication where the client sends a single request to the server and gets a single response back just like a typical function call. But HTTP 2.0 supports various streaming:

   (i) Unary: Sends a single request and gets a single response back.

   (ii) Client Streaming: The client can send a sequence of messages to the server but the server responds only with a single message.

   (iii) Server Streaming: The client sends a single request to the server and gets a sequence of messages back.

   (iv) Bidirectional Streaming: Enables both client and server to send multiple messages and receive responses simultaneously.

3. Server Push: HTTP 2.0 introduces server push where the server can proactively send data to the client before it explicitly asks it. This means that the server can anticipate the client's needs and push relevant resources to the client's system.

Code Generation

REST API does not provide in-built code generation features whereas gRPC has native code generation features due to its protoc compiler. This is compatible with several languages and particularly beneficial for microservices.

Payload

gRPC uses Protocol Buffer by default to serialize payload data which reduces payload size and improves network efficiency. On the other hand, RESTful API mainly relies on JSON or XML formats to send and receive data. JSON is the most popular and widely used data format that doesn't need a strict format to maintain. It has a straightforward syntax that is easy to understand. In terms of difficulty, Protobuf has a steeper learning curve due to the need to define the schema and set up code generation.

Browser Support

REST is fully supported by all the browsers. But any modern browser still doesn't support RPC protocol. It requires gRPC-web and a proxy layer to perform conversions between HTTP 1.1 and HTTP 2.

Performance

Due to binary serialization, smaller message sizes, and additional features, gRPC offers better speed and is lightweight compared to REST.

Error Handling

RESTful API uses HTTP status codes and payload with an error message to handle the error.

Example: 200 OK, 202 Accepted, 301 Moved Permanently, 400 Bad Request, 403 Forbidden, 404 Not Found, 500 Internal Server Error, 502 Bad Gateway, etc. You can read more about the status codes here: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

gRPC follows a more structured way of handling errors.

• Standard Error Model: In this model, when a gRPC call completes successfully the server returns a OK status to the client. If an error occurs, gRPC returns one of its error status codes.

• Rich Error Model: This model enables servers to return and clients to consume additional error details expressed as one or more protobuf messages. It further specifies a standard set of error message types to cover the most common error (QuotaFailure, PreconditionFailure, BadRequest, etc). When an error occurs, the server returns the appropriate status code along with an optional error message.

  Example: GRPC_STATUS_CANCELLED, GRPC_STATUS_DEADLINE_EXCEEDED, GRPC_STATUS_UNIMPLEMENTED, GRPC_STATUS_UNAVAILABLE

Which one to use?

REST

To build public web service API, you can use REST because it is flexible and supported by all browsers. It is easier to maintain and uses the standard HTTP methods to perform operations on resources.

gRPC

REST and gRPC both are used in a microservices architecture. gRPC is generally used for internal communication between these services. If the priority is high performance, low latency, and real-time communication, then gRPC will be the best choice.

Conclusion

Overall both REST and gRPC have their advantages and disadvantages based on different scenarios. Ultimately, the choice between REST and gRPC (or any other communication protocol) should be made after a careful analysis of the project architecture, requirements, scalability, and the company's goal.