# REST, GraphQL, gRPC and Webhooks: Choosing a Style — API Design and Versioning

Source: https://www.geekswithgeeks.com/en/api-design/pr-choosing-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.

```text
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
```

**Quiz:** Which style suits fast, typed internal service-to-service calls?

- [ ] Email
- [x] gRPC
- [ ] FTP only
- [ ] Screen scraping

*Answer:* gRPC. gRPC uses compact Protobuf messages over HTTP/2 with generated typed clients.