3 MIN Read

Last Updated on July 28, 2021 by Team Wobot

gRPC and HTTP are two popular models of API design used by software developers worldwide. But which one should you choose? Here’s a detailed comparison between them.


gRPC (gRPC Remote Procedure Calls) is an open-source remote procedure call (RPC) system initially developed at Google in 2015. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts. It generates cross-platform client and server bindings for many languages. The most common usage scenarios include connecting services in microservices style architecture and connecting mobile devices, browser clients to backend services.

gRPC Strengths:
  • gRPC messages are serialized using Protocol buffer, a binary message format. Protobuf serializes quickly on the server and client.
  • The gRPC specification is prescriptive about the format a gRPC service must follow.
  • gRPC allows clients to specify how long they are willing to wait for an RPC to complete.
gRPC Weaknesses:
  • It’s not possible to directly call a gRPC service from a browser.
  • Protobuf’s binary format isn’t human-readable.

Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services. Web services that conform to the REST architectural style, called RESTful Web services, provide interoperability between computer systems on the internet. RESTful Web services allow the requesting systems to access and manipulate textual representations of Web resources by using a uniform and predefined set of stateless operations. Other kinds of Web services, such as SOAP Web services, expose their own arbitrary sets of operations.

REST Strengths:
  • It is simple to build and adapt.
  • Low use of resources.
  • With the initial URI, the client does not require routing information.
  • Process instances are created explicitly.
REST Weaknesses:
  • It is synchronous, request/response protocol.
  • Latency in request processing times.
  • High bandwidth usage.
Comparison Between REST/HTTP and gRPC
1.REST/HTTP uses HTTP 1.1 as its underlying Transport ProtocolgRPC uses HTTP 2 as its underlying Transport Protocol
2.REST uses JSON, which is text and largergRPC uses Protocol buffer to serialize payload data, which is binary and smaller.
3.REST, it’s often loose and optional. It can be defined via OpenAPI but it is not mandatory.The API contract in gRPC is strict and required to be clearly defined in the proto file.
4.In REST, we must use a third-party tool like OpenAPI and SwaggerCode generation is built-in in gRPC with the help of protocol buffer compiler
5.There is only one way request i.e from client to server in RESTStreaming is Bi-directional in gRPC
6.REST is supported by all browsers around the worldgRPC requires gRPC-web a proxy layer to convert from HTTP 1.1 to HTTP 2
7.Higher Latency and SlowerLower Latency and High Throughput
Latency and Performance:
S. No.Time Required ForLatency (s)Latency (s)System Specs
1.Conversion of Image to Request Format0.560.06On All Systems Specifications
2.Inference of EfficientDet-D10.470.41Intel Core i7 6th gen i7-6600U @2.60GHz
3.Inference of EfficientDet-D00.340.32Intel Core i7 6th gen i7-6600U @2.60GHz
4.Inference of EfficientDet-D20.610.54Intel Core i7 6th gen i7-6600U @2.60GHz
5.Inference of EfficientDet-D30.820.76Intel Core i7 6th gen i7-6600U @2.60GHz
6.Inference of EfficientDet-D41.231.04Intel Core i7 6th gen i7-6600U @2.60GHz
7.Inference of EfficientDet-D00.540.48Intel Core i7 6th gen i7-6500U @2.50GHz
8.Inference of EfficientDet-D10.490.75Intel Core i7 6th gen i7-6500U @2.50GHz
9.Inference of EfficientDet-D21.901.20Intel Core i7 6th gen i7-6500U @2.50GHz
10.Inference of EfficientDet-D32.972.31Intel Core i7 6th gen i7-6500U @2.50GHz
11.Inference of EfficientDet-D45.213.94Intel Core i7 6th gen i7-6500U @2.50GHz

1. Microservices

Low Latency and high throughput communication and Strong API Contract

2. Polyglot Environments

Code generation out of the box for many languages

3. Point to Point Real-Time Communications

Excellent support for bidirectional streaming

4. Network Constrained Environments

Lightweight message format


1. Use of a Uniform Interface (UI)

Resources should be uniquely identifiable through a single URL, and only by using the underlying methods of the network protocol, such as DELETE, PUT and GET with HTTP, should it be possible to manipulate a resource.

2. Client-server Based

There should be a clear delineation between the client and the server. UI and request-gathering concerns are the client’s domain. Data access, workload management, and security are the server’s domain. This loose coupling of the client and server enables each to be developed and enhanced independently of the other.

3. Stateless Operations

All client-server operations should be stateless, and any state management that is required should take place on the client, not the server.

4. RESTful Resource Caching

All resources should allow caching unless explicitly indicated that caching is not possible.

5. Layered System

REST allows for an architecture composed of multiple layers of servers.

6. Code on Demand

​​​​​​​Most of the time, a server will send back static representations of resources in the form of XML or JSON. However, when necessary, servers can send executable code to the client.