gRPC v.s. REST v.s. others
gRPC is roughly 7 times faster than REST when receiving data & roughly 10 times faster than REST when sending data for this specific payload. This is mainly due to the tight packing of the Protocol Buffers and the use of HTTP/2 by gRPC
REST is handy in integrating microservices and third-party applications with the core systems.
However, gRPC can find its application in various systems like IoT systems that require light-weight message transmission, mobile applications with no browser support, and applications that need multiplexed streams.
HTTP 1 / 2
REST APIs follow a request-response model of communication that is typically built on HTTP 1.1.REST APIs can also be built on HTTP 2, but the request-response model of communication remains the same, which forbids REST APIs to make the most out of the HTTP 2 advantages, such as streaming communication and bidirectional support.
Browser
REST is fully supported by all browsers. On the other hand, gRPC is still quite limited when it comes to browser support. Unfortunately, it requires gRPC-web and a proxy layer to perform conversions between HTTP 1.1 and HTTP 2.
When to use gRPC vs REST?
- despite the many advantages gRPC offers, it has one major obstacle: low browser compatibility. Consequently, gRPC is a bit limited to internal/private systems.
- gRPC should also be considered for mobile applications since they do not need a browser and can benefit from smaller messages, preserving mobiles’ processors’ speed.
- gRPC architectural style has promising features that can (and should) be explored. It is an excellent option for working with multi-language systems, real-time streaming, and for instance, when operating an IoT system that requires light-weight message transmission
others APIs
