Lesson 4 / 27

REST, GraphQL, gRPC and Webhooks: Choosing a Style

Match the API style to the consumers and the use case.

No style is best everywhere

REST/HTTP+JSON is the default for public and partner APIs: simple, cacheable, understood by every tool. GraphQL lets clients ask for exactly the fields they need in one request, which suits many different front-ends over a rich graph of data, at the cost of harder caching, rate limiting and security around expensive queries. gRPC (Protocol Buffers over HTTP/2) is compact and fast with strongly typed contracts and streaming, a strong fit for internal service-to-service calls, though less convenient from browsers. Webhooks reverse the direction: your server calls the consumer when an event happens, instead of the consumer polling. Many companies combine them: REST for the public API, gRPC internally, webhooks for events. Choose by who the consumers are and what they need, not by fashion.

A decision table

A starting point; your constraints may differ.

Situation                                          Good first choice
Public / partner API, many unknown clients          REST + OpenAPI
Many UIs needing different shapes of the same data  GraphQL
Internal microservice calls, low latency, streaming gRPC
"Tell me when X happens" to external systems         Webhooks (signed, retried)
Bulk data export / analytics                        files or streaming, not chatty REST

Quick check: Which style suits fast, typed internal service-to-service calls?

  • Email
  • gRPC
  • FTP only
  • Screen scraping
Answer

gRPC — gRPC uses compact Protobuf messages over HTTP/2 with generated typed clients.