API Vocabulary for Backend Developers: REST, GraphQL, and gRPC

Backend developers discuss APIs in design reviews, code reviews, technical interviews, and client meetings. Whether you are designing a new service, reviewing a colleague’s API contract, or explaining your choices to a solutions architect, knowing the precise English vocabulary for REST, GraphQL, and gRPC is essential. This guide gives you the terms and the phrases to use them in context.

REST API Vocabulary

REST (Representational State Transfer) remains the most common API style. Its vocabulary is widely used in job descriptions, technical interviews, and API documentation.

Endpoint — a specific URL that represents a resource or action in an API. “The /users/{id} endpoint returns the profile for the specified user.”

Resource — the entity or object that an API exposes. In REST, resources are nouns: /orders, /products, /users. “RESTful design organises APIs around resources, not actions — use /orders rather than /createOrder.”

HTTP method / verb — GET, POST, PUT, PATCH, DELETE. Each method conveys intent. “We use PATCH rather than PUT for partial updates because PATCH is semantically more appropriate when you are only changing one field.”

Status code — the three-digit HTTP response code indicating the outcome of a request. Common codes: 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorised, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests, 500 Internal Server Error.

Payload — the data body of a request or response, typically JSON or XML. “The POST request payload must include both userId and amount fields.”

Idempotent — an operation that produces the same result whether it is executed once or many times. GET, PUT, and DELETE are idempotent; POST is not. “We chose PUT over POST for this operation precisely because idempotency is important — clients may retry after a timeout.”

Rate limiting — restricting how many requests a client can make within a given time window. “The API enforces a rate limit of 1,000 requests per minute per API key; clients exceeding this receive a 429 response.”

Pagination — splitting large collections into pages. Common strategies: offset-based (?page=2&limit=20), cursor-based, or keyset-based. “For this feed endpoint, we use cursor-based pagination to ensure consistent results even when new items are added between requests.”

Versioning — managing changes to an API over time without breaking existing clients. Common approaches include URL versioning (/v1/users) and header versioning. “We bump the major version only for breaking changes; additive changes are backwards compatible.”

GraphQL Vocabulary

GraphQL is a query language for APIs developed by Facebook (Meta). Its vocabulary is distinct from REST and important to know for roles in modern product engineering.

Query — a read operation in GraphQL that retrieves data. Unlike REST, a single GraphQL query can fetch data from multiple resources in one request. “The client sends a single query asking for the user’s name, their last five orders, and each order’s status.”

Mutation — a write operation in GraphQL (create, update, or delete). “We defined a createOrder mutation that accepts the product IDs and quantities and returns the new order ID.”

Resolver — a function on the server that handles a specific field in a GraphQL query or mutation. Each field in the schema maps to a resolver. “The user.orders resolver makes a database call to fetch all orders associated with that user ID.”

Schema — the type system definition that describes all possible queries, mutations, subscriptions, and their return types in a GraphQL API. Written in Schema Definition Language (SDL). “The schema is the contract between the frontend and backend teams; any change to it requires a discussion.”

Fragment — a reusable piece of a GraphQL query that can be shared across multiple queries to avoid repetition. “We extracted the product fields into a fragment so that both the product list and the product detail queries can reuse it.”

N+1 problem — a performance issue where a query triggers one database call for the parent object and then one additional call for each child object, rather than fetching all related data in a single query. Commonly solved with DataLoader. “We were seeing significant latency in the orders resolver because of an N+1 problem; DataLoader batching reduced it by 90%.“

gRPC Vocabulary

gRPC is a high-performance Remote Procedure Call framework developed by Google. It is widely used for internal service-to-service communication.

Proto / Protocol Buffers — the Interface Definition Language (IDL) used to define gRPC service contracts and message schemas. Compiled to code in multiple languages. “We define all our message types and service interfaces in .proto files; the generated code handles serialisation automatically.”

Service definition — the gRPC equivalent of an API specification, defined in a .proto file. It lists the RPC methods a service exposes and the request/response message types for each. “The service definition acts as our contract; backend and frontend teams agree on it before either side starts implementation.”

Streaming — gRPC supports four communication patterns: unary (single request, single response), server streaming, client streaming, and bidirectional streaming. “We use server-side streaming for the real-time event feed so the client receives updates without polling.”

Deadline / timeout — in gRPC, clients specify a deadline by which they expect a response. If the server does not respond in time, the client receives a DEADLINE_EXCEEDED error. “Always set a deadline on gRPC calls; without one, a slow downstream service can cause your entire call tree to hang indefinitely.”

Interceptor — middleware that runs before or after a gRPC call on either the client or server side, used for logging, authentication, or metrics. “We added a server-side interceptor to log the method name, status code, and duration of every RPC call.”

Example Sentences in Context

1. “We designed the payment endpoint to be idempotent by accepting a client-generated idempotency key; if a client retries after a timeout, our server detects the duplicate key and returns the original response without processing the payment twice.”

2. “The move from REST to GraphQL eliminated the over-fetching problem on the mobile app — clients now request exactly the fields they need rather than receiving a large JSON object and discarding most of it.”

3. “Each resolver in our GraphQL layer has a strict timeout; if the database call takes longer than 200 ms, the resolver returns a partial result rather than blocking the entire query.”

4. “Our internal services communicate via gRPC; the .proto service definitions are stored in a shared repository and treated with the same rigour as a public API contract — breaking changes require a deprecation period.”

5. “When discussing API versioning, I always distinguish between additive changes, which are backwards compatible and do not require a version bump, and breaking changes such as removing a field or changing a status code, which require incrementing the major version.”