API Design Interviews: Defending your choices
When an interviewer asks you to design an API, they are not testing whether you know how to write a generic routing function. They are testing your ability to establish a formal, predictable contract between the client and the server.
In a full-stack system, a well-designed API hides the complexity of the database and business logic from the frontend. During an interview, you will frequently be presented with a business problem and asked to choose the communication protocol. The fastest way to fail this round is to say, “I would use GraphQL because it is modern.” Professional engineers do not choose tools based on trends; they choose them based on strict architectural trade-offs.
Defending REST: The Resource-Based Standard
Representational State Transfer (REST) remains the most common pattern for web APIs. If the interview prompt revolves around standard CRUD (Create, Read, Update, Delete) operations, REST is your default answer.
When defending a REST architecture, emphasize the following principles to the interviewer:
- Statelessness: Explain that every request from the client must contain all the information necessary for the server to understand and process it, meaning the server does not store “session” context between requests.
- Predictability: Discuss how you organize the system into Resources (like Users or Orders) identified by URLs. A request to
/api/v1/users/42predictably returns data for the user with the ID of 42. - Semantic Communication: Prove your maturity by stating you enforce a “Uniform Interface” using standard HTTP methods (GET, POST, PUT, PATCH, DELETE) and meaningful status codes (e.g., 201 for Created, 403 for Forbidden) rather than just returning generic 200 OK or 500 Error responses.
Defending GraphQL: Managing Client Complexity
While REST is resource-centric, GraphQL is query-centric. You should propose GraphQL in an interview when the prompt involves a highly complex frontend with deeply nested data requirements.
- Avoiding Over-fetching: Explain that in REST, calling a user endpoint might return 50 fields when the UI only needs the name. In GraphQL, the client defines exactly what data it needs, saving massive amounts of bandwidth.
- The Architectural Trade-off: This is where senior candidates shine. Acknowledge that while GraphQL provides immense flexibility for the frontend, it moves the complexity directly to the backend.
- Addressing the N+1 Problem: If you suggest GraphQL, immediately tell the interviewer how you will mitigate the “N+1” query problem, where a single request accidentally triggers hundreds of small database lookups. Mentioning data loaders or eager loading proves you understand the server-side cost of frontend flexibility.
/**
* Example of a standardized REST API Response wrapper.
* In an interview, writing out a clean contract like this shows
* you prioritize predictability and pagination metadata over raw data dumping.
*/
const apiResponse = {
data: [
{ id: "eb3f-4122", title: "Defending API Choices", status: "published" }
],
meta: {
total_count: 150,
page_size: 20,
next_cursor: "MjAyNi0wMy0wNVQxMjo1ODozNlo=" // Standardizing cursor pagination
},
request: {
id: "req_889234",
timestamp: "2026-03-05T12:58:36Z"
}
};
Defending WebSockets: The Real-Time Requirement
If the interviewer asks you to design a chat application, a collaborative document editor, or a live financial ticker, standard HTTP architecture will fail.
- The Problem with Polling: Explain that having the client ask the server for new data every five seconds (short polling) creates massive network overhead, wasting database and server resources on empty responses.
- The WebSocket Solution: Propose WebSockets to provide a full-duplex, bidirectional communication channel over a single TCP connection. Both the client and server can push data at any time without HTTP header overhead.
- The Stateful Trade-off: Once again, highlight the cost. Unlike stateless REST APIs, a WebSocket server must keep track of every active connection in its memory. Mentioning that this makes horizontal scaling difficult and requires a central Pub/Sub broker (like Redis) shows elite system design knowledge.
Learning Point: If the prompt only requires the server to push data to the client (like a live sports score), suggest Server-Sent Events (SSE) instead of WebSockets. Noting that SSE is architecturally simpler, easier to secure, and features native browser reconnection logic demonstrates that you do not over-engineer solutions just to sound impressive.
Popular Guides