API, REST, gRPC and MCP compared 9 questions in 6 chapters

An API is a contract: the operations, data and errors a caller can rely on, without depending on the implementation behind them. REST, gRPC and MCP are ways of realizing that contract, not replacements for the idea of an API. REST models resources over HTTP. gRPC exposes typed procedures over HTTP/2 and Protocol Buffers. MCP lets an AI host discover tools at runtime so the model can choose what to call.

REST is an architectural style, not a synonym for JSON over HTTP. Fielding adds client-server, stateless requests, cache labels, a uniform interface, a layered system, and optional code-on-demand. The uniform interface itself requires identified resources, representations, self-descriptive messages, and hypermedia as the engine of application state. Most production HTTP APIs stop at resources, methods and status codes, and treat hypermedia as optional. That is a common engineering choice, not a claim that every constraint is satisfied.

Safety means the method is essentially read-only. RFC 9110 defines GET, HEAD, OPTIONS and TRACE as safe. Idempotency means repeating the same request has the same intended effect as doing it once; PUT, DELETE and all safe methods are idempotent, and POST is not. PATCH, defined separately, is neither safe nor idempotent as specified. I would only retry automatically when the method is idempotent, and I would cache only when the response says I may.

I treat the OpenAPI description as the contract and prefer compatible extensions over new versions: add optional fields, keep existing meaning, and make clients tolerant of additions. If a breaking change is unavoidable, I would version the media type and negotiate it, rather than putting a version segment in the URL. That is also what Zalando's public RESTful API Guidelines require. Format selection with Accept is a different problem from evolving the semantic contract.

gRPC is a remote procedure call framework. You declare messages and services in a proto file, generate stubs, and call methods instead of hand-writing URLs. The default stack is HTTP/2 for transport and Protocol Buffers for the contract. There are four method kinds: unary, server streaming, client streaming and bidirectional streaming. I always set a deadline, because there is no default, and I treat the result as a gRPC status, not as an HTTP status.

gRPC keeps a long-lived HTTP/2 connection and multiplexes many RPCs as streams on that connection. A TCP load balancer only sees the connection, so all of those calls can stick to one backend. I would use an HTTP/2-aware proxy or client-side balancing that picks a backend per call. Browsers cannot speak native gRPC, because they do not expose raw HTTP/2 frames; gRPC-Web plus a proxy such as Envoy covers unary and server streaming, but not typical client or bidirectional streaming.

I treat field numbers as immutable identifiers. Adding a field is safe: old binaries ignore it, and new binaries see a default when old senders omit it. Removing a field is safe only if I reserve its number, and preferably its name, so nobody reuses it. Changing a field number, or recycling a deleted number, is a breaking wire change. I use the binary encoding for compatibility-sensitive interchange, because the JSON mapping is stricter.

MCP is a JSON-RPC protocol that lets an AI host discover tools, resources and prompts at runtime and let a language model choose among them. A host creates one client per server. Current transports are stdio and Streamable HTTP; the older HTTP plus SSE transport is deprecated. The 2026 revision made the protocol stateless: there is no initialize handshake, and every request carries the protocol version and client capabilities.

I choose based on who the caller is, not on which name is fashionable. REST fits public and partner HTTP clients, browsers, caches and OpenAPI toolchains. gRPC fits internal, typed, often streaming service-to-service calls, as long as load balancers understand HTTP/2. MCP fits an AI host that must discover tools at runtime and let a model choose among them, usually as a façade over an existing API.