API DESIGN: GRPC VS HTTP
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 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.
- 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.
- 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.
- 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 Protocol||gRPC uses HTTP 2 as its underlying Transport Protocol|
|2.||REST uses JSON, which is text and larger||gRPC 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 Swagger||Code 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 REST||Streaming is Bi-directional in gRPC|
|6.||REST is supported by all browsers around the world||gRPC requires gRPC-web a proxy layer to convert from HTTP 1.1 to HTTP 2|
|7.||Higher Latency and Slower||Lower Latency and High Throughput|
Latency and Performance:
|S. No.||Time Required For||Latency (s)||Latency (s)||System Specs|
|1.||Conversion of Image to Request Format||0.56||0.06||On All Systems Specifications|
|2.||Inference of EfficientDet-D1||0.47||0.41||Intel Core i7 6th gen i7-6600U @2.60GHz|
|3.||Inference of EfficientDet-D0||0.34||0.32||Intel Core i7 6th gen i7-6600U @2.60GHz|
|4.||Inference of EfficientDet-D2||0.61||0.54||Intel Core i7 6th gen i7-6600U @2.60GHz|
|5.||Inference of EfficientDet-D3||0.82||0.76||Intel Core i7 6th gen i7-6600U @2.60GHz|
|6.||Inference of EfficientDet-D4||1.23||1.04||Intel Core i7 6th gen i7-6600U @2.60GHz|
|7.||Inference of EfficientDet-D0||0.54||0.48||Intel Core i7 6th gen i7-6500U @2.50GHz|
|8.||Inference of EfficientDet-D1||0.49||0.75||Intel Core i7 6th gen i7-6500U @2.50GHz|
|9.||Inference of EfficientDet-D2||1.90||1.20||Intel Core i7 6th gen i7-6500U @2.50GHz|
|10.||Inference of EfficientDet-D3||2.97||2.31||Intel Core i7 6th gen i7-6500U @2.50GHz|
|11.||Inference of EfficientDet-D4||5.21||3.94||Intel Core i7 6th gen i7-6500U @2.50GHz|
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.