Every two years, someone declares the death of REST and the arrival of the next big thing. The contenders: SOAP, GraphQL, gRPC, tRPC, JSON:API, HATEOAS, Falcor, OData. Most have real use cases, but none have displaced REST as the default. Misreading this — "REST is legacy, modern APIs are X" — leads to poor architectural decisions at companies whose moat is an easy-to-consume API.

Here's the reality, as if defending choices in a design review.

REST is the default and will remain so. Every engineer knows it, every tool supports it, and its failure modes are well-understood. A REST API doesn't require teaching your customer's intern. They can curl an endpoint, read the JSON, and integrate by Tuesday. In 2026, the cost-to-integrate of a well-designed REST API is the lowest, and that's what matters in B2B API economics. REST being "old" is irrelevant. SQL and email are older and still default because ubiquity beats novelty when the customer pays the integration cost.

GraphQL was overhyped, then under-hyped, now rightly placed. It's ideal when (a) clients need to over-fetch from many resources, (b) multiple client teams have diverging needs, and (c) you have the engineering depth to run a GraphQL backend. Mostly, this is Facebook, Shopify, GitHub, and a few others. For everyone else — and this is what consultants didn't tell you in 2018 — GraphQL is operational pain you don't need: N+1 queries, non-HTTP caching, depth-limiting, schema evolution issues, resolver CPU drain. A team of three doesn't benefit from GraphQL. A team of fifty might. Few are in between.

GraphQL is alive and right for specific workloads. The "all APIs should be GraphQL" wave peaked in 2020 and broke. If you adopted GraphQL for its modernity, you're likely regretting the cache invalidation. If you needed the multi-client fan-out, you're fine.

gRPC is correct internally and a tax externally. gRPC over HTTP/2 with protobuf is fast and type-safe — ideal for internal service-to-service in systems big enough to care about wire cost. Google built it, uses it, and your service mesh probably supports it. Inside your infrastructure, where you control both ends, it's a win.

External gRPC — exposing it to customers — is worse than supporters admit. Browsers can't natively speak it (gRPC-Web is a hack). Most engineers haven't touched protobuf. Tooling is worse than REST. Customer integration cost spikes. Companies shipping gRPC externally need the perf — TensorFlow Serving, financial data feeds, high-throughput telemetry. If you're not one of those, don't expose gRPC publicly. Internal: yes. External: only if necessary.

tRPC and "type-safe RPC" frameworks are a TypeScript-monorepo phenomenon. If your frontend and backend are TypeScript in the same repo, tRPC boosts productivity. End-to-end types, zero wire-format ceremony, better developer experience than REST for that setup. The catch: "TypeScript" and "monorepo." A Python backend can't use it. A separate Swift mobile team can't use it. If you might expose this API to a customer, you can't, because they don't have your repo. tRPC suits its niche but isn't a general API strategy.

OpenAPI is the spec everyone agrees to ignore. OpenAPI (formerly Swagger) describes REST APIs. Ideally, you write the spec, generating docs, client SDKs, server stubs, validation, and tests. In practice, teams hand-edit YAML that drifts from implementation or generate specs from code with lying annotations. Teams who get this right treat the spec as the source of truth and generate everything else — including the server. That works. The middle ground (spec from code, docs from spec) rots because nothing fails if the spec is wrong, so it gets wrong.

Starting fresh in 2026: write the OpenAPI spec first, generate server scaffolding, SDKs, and docs from it, and make CI fail if the spec doesn't match the server. This discipline yields better APIs.

Streaming and async are an active frontier. Server-Sent Events (SSE), WebSockets, and long-polling have been around, but the LLM era made streaming responses essential. OpenAI's SSE-based streaming response is now the standard. If shipping an API returning generated content, plan for streaming from day one. Don't add streaming later — client patterns differ too much.

Webhooks remain standard for server-to-server async: HMAC-signed payloads, at-least-once delivery, replay tools. Pub-sub APIs (Pusher, Ably, Centrifugo) suit customers wanting client push without infrastructure. Polling is still fine for low-frequency checks; don't be ashamed.

What's actually changing. AI integrations reshape API design in two ways. First: tool-use specs. OpenAI's function-calling format and Anthropic's tool definitions are JSON Schema subsets, suggesting a future where every API publishes a machine-readable tool spec for LLMs. Without a clean tool spec by 2027, you'll be invisible to the agentic-AI integration market. Second: structured outputs. APIs returning well-typed structured data (not a JSON blob with a string body) will be more valuable, composing with LLM pipelines without an extraction step. Build for that.

Practical advice for a team picking an API style in 2026.

If you're a B2B SaaS with external customers: REST with OpenAPI, idempotency keys on mutations, cursor pagination, well-designed errors, SDKs in TS and Python. This is boring and correct.

If you're a consumer-product company with one frontend and one backend, both yours: REST is fine. tRPC is fine. Either works. Don't agonize.

If you have multiple client teams (web, iOS, Android) consuming the same backend with differing data needs: consider GraphQL. Budget for the operational overhead.

If you have internal microservices talking at high throughput: gRPC. Don't expose it externally.

If building an LLM-callable API or agentic-tool surface: REST with strict OpenAPI, and publish a function-calling spec separately. The future is agents calling your endpoints.

The most important point: the technology stack isn't the bottleneck. The bottleneck is whether the team designing the API treats it as a product. A great REST API beats a mediocre GraphQL one every time. A documented gRPC service beats an undocumented REST service every time. Pick the substrate, then do the work — design, docs, errors, latency, backwards compatibility, the whole thing.

REST won the substrate fight. The substrate isn't the interesting part.