For full text search please use the '?' prefix. e.g. ? Onboarding

gRPC VS REST

Why Remote procedure call (RPC) is a protocol and not Representational State Transfer (REST), if RPC can use HTTP and REST use HTTP ?

RPC and REST are two different architectural styles for designing web services. RPC is more prescriptive in its approach and typically defines a specific protocol for communication between the client and the server. In contrast, REST is more flexible and relies on existing HTTP protocols and conventions.

RPC typically involves the client invoking a method on a remote server and receiving a response. The protocol used for this communication is often defined by the RPC framework being used, such as gRPC or Apache Thrift. This protocol defines how the data is encoded, how errors are handled, and other details of the communication.

On the other hand, REST relies on the existing HTTP protocol for communication between the client and server. RESTful APIs define a set of conventions for using HTTP methods (such as GET, POST, PUT, and DELETE) and status codes to interact with resources. However, the specific details of the communication (such as how data is encoded) are left up to the client and server to decide.

So, while both RPC and REST can use HTTP as a transport protocol, the key difference is that RPC defines a specific protocol for communication, while REST relies on the existing HTTP protocol and conventions.

Google Remote procedure call (gRPC) vs Representational State Transfer (REST): comparing APIs architectural styles

https://www.imaginarycloud.com/blog/grpc-vs-rest/

  • What is an API ?

    An API specifies the types of requests that one application (web page or mobile app) can make to another and further establishes: how to make those requests; which data formats to use; and the practices that users have to follow.

    This article compares gRPC (Google Remote Procedure Call) and REST (Representational State Transfer) because they represent the two most popular architectural styles when creating APIs

  • The most used architectural style is the REST API. However, there are three main models when building an API: RPC (Remote Procedure Call), REST (Representational State Transfer), and GraphQL. In this article, we will focus on the first two.

  • What is RPC?

    RPC uses a client-server model. The requesting server (in other words, the client) requests a message that is translated by the RPC and sent to another server. Once the server receives the request, it sends the response back to the client. While the server is processing this call, the client is blocked, and the internal message passing within servers is hidden.

    Further, RPC allows the client to request a function in a particular format and receive the response in the exact same format. Nonetheless, the method of submitting a call with RPC API is found in the URL. RPC supports remote procedure calls both in local and distributed environments.

    Like a REST API, RPC also establishes the rules of interaction and how a user can submit "calls" (requests) to invoke methods that communicate and interact with the service.

  • What is gRPC?

    gRPC stands for Google Remote Procedure Call and is a variant based on the RPC architecture. This technology follows an RPC API's implementation that uses HTTP 2.0 protocol, but HTTP is not presented to the API developer nor to the server. Hence, there is no need to worry about how the RPC concepts are mapped to HTTP, which reduces complexity.

    Overall, gRPC aims to make data transmissions between microservices faster. It is based on the approach of determining a service, establishing the methods and respective parameters to enable remote calling and return types.

    Moreover, it expresses the RPC API model in an IDL (interface description language), which offers a more straightway to determine remote procedures. By default, the IDL uses Protocol Buffers (but other alternatives are also available) to describe the service interface as well as the payload messages' structure.

  • gRPC vs REST: comparison table

Features gRPC REST

HTTP 1.1 vs HTTP 2

Follows a client-response model of communication and is built on HTTP 2, which allows for: streaming communication and bidirectional support.

Follows a request-response model of communication and is typically built on HTTP 1.1.

Browser Support

Limited browser support. gRPC requires gRPC-web and a proxy layer to perform conversions between HTTP 1.1 and HTTP 2.

Universal browser support.

Payload Data Structure

gRPC uses Protocol Buffer by default to serialize payload data.

REST mainly relies on JSON or XML formats to send and receive data.

Code Generation Features

gRPC has native code generation features.

Developers must use a third-party tool like Swagger or Postman to produce code for API requests.

  • When to use gRPC vs REST?

    As mentioned, despite the many advantages gRPC offers, it has one major obstacle: low browser compatibility. Consequently, gRPC is a bit limited to internal/private systems.

Backlinks