The 30 second answer
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.
An application programming interface (API) is a contract that lets one piece of software use another without depending on its internal implementation. The contract names operations or resources, the data that goes in and out, error behaviour, and usually some rules about evolution and authentication. That idea is older than the web. A Java interface, a database driver's call surface, and a network service are all APIs.
REST, gRPC and MCP sit one layer down. They are styles or protocols for realizing an API, typically over a network (or, for some MCP servers, over a local process). Saying "we should use REST instead of an API" mixes those layers.
A useful way to keep the layers straight:
| Layer | What it answers | Examples |
|---|---|---|
| API (the idea) | What can a caller do, and what do the messages mean? | Search products, create an order, list tools |
| Architectural style or protocol | How are those operations modelled and exchanged? | REST resources and HTTP; gRPC service methods; MCP JSON-RPC methods |
| Transport and encoding | How do bytes move, and in what shape? | HTTP with JSON; HTTP/2 with protobuf; stdio or Streamable HTTP with JSON-RPC |
| Implementation | What framework or generated code do we use? | Spring Boot controllers, protobuf stubs, an MCP SDK |
Two APIs can offer the same business capability through different styles. A product-search service might expose a REST collection, a gRPC Search RPC, and an MCP search_products tool that wraps one of those backends. The capability is the API; REST, gRPC and MCP are the access methods.
Alternate interview scenarios
"Should we use REST instead of an API?"
That question confuses the contract with one way of exposing it. I would restate it as: who are the callers, and which style fits them? Public HTTP clients usually want REST. Internal service-to-service calls often want gRPC. An assistant that must discover capabilities at runtime wants MCP, usually as a façade over an existing REST or gRPC API rather than as a replacement for it.
"Is GraphQL or gRPC a replacement for having an API?"
No. Those are also ways of realizing an API. The interview signal is to separate the business contract from the access method, then justify the method with caller, tooling and operational constraints.
Sources (3)
- Fielding dissertation, Chapter 5: Representational State Transfer (REST)ics.uci.edu
- gRPC core conceptsgrpc.io
- Model Context Protocol specification, revision 2026-07-28modelcontextprotocol.io