REST Is Back. tRPC, GraphQL, gRPC Lost.

Between 2019 and 2024, the API conversation was dominated by alternatives to REST. GraphQL was going to fix over-fetching. tRPC was going to give us end-to-end type safety. gRPC was going to replace the lot with binary speed. Every "modern" stack tutorial included at least one of them.

By 2026, the smart teams I work with are quietly going back to plain HTTP, JSON, and OpenAPI 3.1. Not because REST is good. Because the alternatives turned out to be worse than they looked.

What Each Alternative Promised

GraphQL sold a single endpoint, query exactly what you need, no over-fetching. Strong types from the schema. Federated graphs across services.

tRPC sold zero-codegen end-to-end type safety in TypeScript monorepos. Call your backend like a function. The compiler catches everything.

gRPC sold binary protocols, HTTP/2 streaming, and language-agnostic codegen from .proto files. Half the wire size of JSON, faster parsing, real bidirectional streaming.

All three were technically correct. All three lost.

What Actually Happened

GraphQL turned into a complexity tax. The N+1 problem moved one layer up. DataLoader patterns are necessary but rarely understood. Persisted queries are necessary but rarely shipped. The schema becomes a liability the moment two clients want different shapes. Caching is a research project. By 2025 most "GraphQL APIs" were a single query endpoint with a half-dozen actually-used queries—reinventing REST badly.

tRPC was beautiful in the demo and painful in production. Coupling your client and server through a single TypeScript type works fine until you have a mobile app, a third-party integration, a Go service, or a single backend rewrite that breaks every consumer simultaneously. Type safety is great. Tightly coupling deployment of two things that should ship independently is not.

gRPC was always a Google solution to a Google problem. The wire savings don't matter at indie scale. The tooling overhead does. Browser support is a known sore point. Debugging a binary protocol with grep is genuinely worse than curl localhost:3000/users | jq. Most teams that adopted gRPC kept a JSON gateway in front of it anyway.

What REST Got That The Others Didn't

The boring REST stack in 2026 has a stack of advantages that compounded while everyone else was busy reinventing:

• OpenAPI 3.1 — schema-first APIs with rigorous typing, code generation in 30+ languages, and runtime validation that beats anything tRPC ever shipped
• Hono / Fastify / Echo — typed REST frameworks that produce OpenAPI specs as a build artifact
• Stoplight / Scalar / Bruno — beautiful API tooling that grew up while GraphQL Playground stagnated
• HTTP caching — built into every CDN, every browser, every reverse proxy. GraphQL cannot match this.
• Idempotent everything — the HTTP verb model is the protocol baked into AWS, Stripe, Cloudflare, and every retry-safe library you depend on
• LLMs read it natively — every model trained on the public web understands REST and OpenAPI. They struggle with gRPC and write GraphQL queries that fail at runtime.

That last point is bigger than people realize. In an agent-driven world, the protocol that LLMs work with most reliably wins. REST + OpenAPI is the lingua franca of MCP servers, agent tool calls, and AI-assisted client generation. The tooling moat is now an LLM moat.

When You Still Want The Alternatives

I am not saying GraphQL, tRPC, and gRPC are dead. I am saying their addressable market shrank:

• GraphQL is genuinely useful for federated data graphs across many services with many varied clients. Shopify and GitHub still ship it for the right reasons.
• tRPC is genuinely useful inside a single Next.js app where the server and client deploy together and there's no other consumer. That's a small, specific niche.
• gRPC is genuinely useful for high-volume internal service-to-service calls where you control both ends and the wire savings matter. Mostly that's at Google-scale.

Outside those niches, REST + OpenAPI + a generated typed client beats the alternatives on every axis that matters for shipping.

The Practical Stack For 2026

Here's what I'm using on every new project:

• Hono for the HTTP layer (deploys anywhere, types are excellent)
• Zod for input/output validation (also generates OpenAPI)
• OpenAPI 3.1 spec emitted at build time
• Generated TypeScript clients from the spec, shipped as a workspace package
• Tanstack Query on the frontend, talking to those clients

Type safety: end-to-end. Wire format: JSON, debuggable with curl. Caching: the entire HTTP ecosystem. Mobile client: same generated client. Third-party integration: curl and the OpenAPI page.

It's boring. It's been the right answer for fifteen years. It's the right answer again now.

The hype cycle eats its young. REST quietly outlived all of them.