gRPC vs REST

by Irina Scurtu

gRPC vs REST by Irina Scurtu

Context #

Both gRPC and REST are different architectural approaches for building distributed systems, each with its own fundamental characteristics. Both have their own place in the application ecosystem. The main visible difference being the context in which they are used. REST is more for public-facing APIs and gRPC for downstream APIs. In modern architectures, both gRPC and REST have their rightful place. Even though gRPC is fairly new to the game, it has it's own merits and it will never replace REST. REST(or HTTP APIs to be more specific) will continue to be the 'de facto' standard for creating APIs in the WEB world.

Underlying Principles and Architecture #

Explain the fundamental architectural differences between gRPC and REST. Discuss how gRPC is based on Protocol Buffers and HTTP/2, while REST uses standard HTTP methods and typically exchanges data in formats like JSON or XML.

gRPC #

  • gRPC uses HTTP/2 protocol. This gives us all the perks of using a new protocol version like: performance, reduced latency, and optimized network utilization.
  • gRPC uses Protocol Buffers (protobuf) as its Interface Definition Language (IDL). This is a special language in which we define the types(messages) that can be handled by the server, and service operations. This allows us to define what the server exposes in a language-agnostic way.
  • gRPC requests can be only of type POST
  • Call-a-method look and feel - for us, developers, with gRPC we call methods and pass parameters to the methods, and we get objects as a response

REST #

  • REST APIs can use HTTP/1 or HTTP/2
  • The definition of a REST API is usually exposed trough a standard like Open API, and tools like Swagger
  • REST APIs use the standard HTTP methods (GET, POST, PUT, DELETE, etc.) to manipulate resources identified by URIs. Often these are used to perform CRUD(Create, Read, Update, Delete) operations
  • Make-a-request-to-an endpoint approach - for us, developers with REST APIs, we call endpoints utilizing HTTPClients, and passing in querystrings, request bodies and expecting the response back

Performance and Efficiency Comparison #

Protocol Buffers #

  • uses binary serialization format which is more compact and ligthweight(in some cases)
  • is not always human-readable( but we have tools to aid with that) e.g: Postman, Kreya, Kalisto,
  • is lightweight when it comes to data transmission over the network(due to its binary format and compression)
  • offer a high level of schema flexibility and extensibility. They allows for backward and forward compatibility through versioning and evolving message schemas without breaking changes, making them suitable for applications where data structures might evolve over time.
  • steep and complex learning curve, more setup
  • strongly typed

REST #

  • is a text-based serialisation format
  • is human readable usually using JSON or XML
  • more heavy-weight for network data transfer due to the format
  • offer a high level of schema flexibility and extensibility. Thisflexibility allows for easy serialization of different types of data structures, it can lead to challenges in maintaining data consistency and handling schema evolution across different versions of an API.
  • easy to understand and simple structure
  • lack of strict typing

Service Contracts and Code Generation #

gRPC #

  • has a strict and well-defined service contract, in which we can specify the methods and their parameters and the message types.
  • code-generation out of the box
  • promotes a rigid an strongly typed API definition.
  • straightforward interoperability between different programming languages due to the consistent code generation from the well-defined service contract.

REST #

  • has flexible and loosely defined service contracts relying on HTTP methods and standard data formats like JSON or XML
  • no strict standards or structured schema definitions allowing us to define and design services how we want
  • due to less strict service definitions, it can lead to less consistency in how APIs are implemented in various programming languages. This is usually done using third-party tooling

Tooling and Ecosystem Support #

gRPC provides a more standardized and uniform way of defining APIs and generating code across multiple languages, leading to consistent development experiences. REST ecosystem is more descentralized. We can find a wide array of frameworks and tooling, providing flexibility and options for developers but may lack uniformity.

while gRPC's ecosystem is more standardized and centralized, providing uniform tooling and library support, the REST ecosystem offers extensive diversity and flexibility, leading to a more varied developer experience based on chosen frameworks and tools. Both ecosystems have their respective strengths and benefits, allowing developers to choose based on their specific needs, preferences, and project requirements.

Use Cases and Suitability #

gRPC #

  • high-performance applications where low latency and high throughput are essential. It uses HTTP/2 and binary serialization, making it faster and more efficient than REST in terms of data transfer.
  • microservices environments, gRPC's strong typing and well-defined service contracts streamline communication between microservices. We basically have to have access to the .profo file and we are good to consume the API that exposes the file. It supports bidirectional streaming that can be an advantage for distributed systems.
  • Polyglot/wanna be polyglot environments - the code-generation for various languages from the service contract(.proto file) is makes a consistent experience accross different languages. This allows expose and consume services from different ecosystems.
  • limited browser support - We have gRPC-Web that extends gRPC support to browser-based applications, its full capabilities and features might not be readily available or as seamless as with native gRPC usage in non-browser environments.

REST #

  • due to the textual representation we can say that it has higher overhead and slower performance compared to gRPC
  • for all apps, and public-facing APIs
  • the format of the request/response must be known by the parts trying to communicate
  • fully supported in browser apps without third party tooling

Conclusion and Recommendations: #

In summary, the choice between gRPC and REST depends on various factors such as performance requirements, interoperability, ease of use, and the specific needs of the application. gRPC is ideal for high-performance, microservices, and polyglot environments, whereas REST is more suitable for simpler, publicly accessible APIs and when browser compatibility and human readability are prioritized. Understanding the trade-offs and specific use cases helps in making an informed decision regarding the best-fit technology for a given scenario.

PS: Let me know if I forgot anything

grpc REST