Two services need to talk. They might be in different languages, different organisations, different decades. The history of web services is a history of agreeing on a contract — and the agreement has shifted shape several times. In 2026 we have four credible options. Picking between them is mostly about who you're talking to and what they expect.
REST: still the default
HTTP, JSON, resource-shaped URLs, and an OpenAPI spec. Boring, well-understood, and supported by every language and tool you can name. For public APIs and most external integrations, REST is what people expect and what tooling supports.
The strengths haven't changed: cacheable on the edge, debuggable with curl, easy to mock. The downsides also haven't changed: chatty for related-resource fetches, schema drift if you're lax, easy to design badly.
GraphQL: when the client knows what it needs
The case for GraphQL was always strongest where you have many different consumers (web, mobile, partner apps) that need different shapes of the same underlying data. That case is unchanged in 2026.
What did change:
- Federation matured. Apollo Federation and Mercurius let multiple teams own pieces of one schema without one team becoming the gatekeeper. This addressed the original "one giant schema" pain point.
- Persisted queries became default. Sending a query hash from a known whitelist solves most of the security and caching complaints.
- The tooling settled. Codegen, type-safe clients, and IDE support are now table-stakes good.
We still don't reach for GraphQL on small APIs. The setup cost outpaces the benefit until the consumer count justifies it.
gRPC: for service-to-service
If both sides are services you control, gRPC is hard to beat. Protocol buffers are smaller and faster than JSON. Streaming is first-class. Code generation for clients means you can't accidentally diverge schemas.
The catch: gRPC over the public web is awkward. Browsers need gRPC-Web, which means a translation layer. For browser-facing APIs we stick to REST or GraphQL.
MCP: the new entrant
The Model Context Protocol — a way for AI agents and applications to expose tools and data to each other. It is not a replacement for REST or gRPC; it is a specific contract for "this thing can be used by an LLM."
If your business is going to be consumed by AI agents (and most of them will be), MCP is becoming the lingua franca for that consumption path. It sits on top of JSON-RPC, has a standard manifest, and is supported by every major AI tooling vendor.
Think of MCP as "OpenAPI but for tools an agent can call" — same problem space (publish your contract), different audience (machines that reason).
Which to pick
- Public-facing API for many human-built clients? REST.
- Internal API where the client is your own SPA or mobile app and you ship both? Often REST is still fine. GraphQL if you have several distinct frontends with different shapes.
- Internal service-to-service inside your own platform? gRPC.
- Anything an AI agent will consume? MCP — alongside, not instead of, your existing API.
The trap to avoid
Picking a protocol because it's in fashion. We've audited too many architectures where someone introduced GraphQL for a single-client API, or gRPC inside a system that has one browser frontend. The complexity tax is real. The protocol should serve the integration, not the other way around.
Interoperability is mostly a contract problem, not a transport problem. The conversation with your counterparty about how the contract evolves is more important than the wire format you choose to send it over.