The most mature of the three API technology options is REST (REpresentational State Transfer).
REST was described as the core architectural principle of the World Wide Web in Roy Fielding's doctoral dissertation in 2000.
REST is a client-server interaction architecture that is stateless, cacheable, and convention-based.
The REST is ambiguous. Even though Roy Fielding's doctoral dissertation is excellent, it cannot be used as a specification, and developers interpret REST in a variety of ways.
Google's current implementation of the tried-and-true RPC (Remote Procedure Call) paradigm, in which each request is structured like a function call in a programming language, is known as gRPC.
gRPC evolved from Google's internal infrastructure, where it connected a plethora of large-scale services running across data centers, before being open sourced in 2016.
gRPC clients and servers communicate using HTTP/2 and a compact binary format based on the Protobuf contract. Encoding and decoding gRPC messages in any programming language is very efficient by design.
Because it requires HTTP/2, which browsers do not fully support, gRPC is not a native solution for customer-facing web applications.
GraphQL, which was introduced by Facebook in 2015, represents a different line of API technology evolution.
GraphQL provides an alternative way for browser-based clients to interact with API servers, whereas gRPC focuses on lightning-fast service-to-service communication.
GraphQL allows each client to specify the exact shape of data required for a specific use case and retrieve it all in a single round trip.
GraphQL has very limited utility for inter-service communication. Because the client can request any combination of data fields at once, the response time is limited to the slowest requested field. This means that queries will need to be optimized on a continuous basis based on usage patterns.