GraphQL or REST for a new public API?

It depends on who the clients are and how varied their needs are.

GraphQL fits well when: - several first-party clients (web, mobile) need different shapes of the same data, and you want to avoid over-fetching and N endpoints; - the domain is a rich graph (users → posts → comments → reactions); - you want a typed schema as the contract, with codegen for clients.

Costs to plan for: - HTTP caching is harder (mostly POST to one endpoint). You'll rely on client caches or persisted queries. - Performance safety: clients can craft expensive nested queries. You need query depth/complexity limits and DataLoader batching to avoid N+1 queries. - Authorization per field or type, not per endpoint.

REST fits well for public/partner APIs: easy to understand, cacheable, and consumable with curl, with standard rate limiting per endpoint. OpenAPI gives you typed clients too.

A common split: REST (+ OpenAPI) for partners, GraphQL (or tRPC for a TypeScript monorepo) for your own apps, if the flexibility is worth it to you.

From experience maintaining both: if you pick GraphQL, use persisted queries for your own clients from day one. You get cacheable GET requests and protection against arbitrary expensive queries, and it's much harder to retrofit later.