Which statement best describes the recommended default API approach in system design interviews?

Which statement best describes the recommended default API approach in system design interviews?

• A. Always start with GraphQL for flexibility.
• B. Default to REST; reach for GraphQL, gRPC, SSE, or WebSockets only when REST cannot meet needs.
• C. Use SSE for public APIs.
• D. Use WebSockets for all client interactions.

Answer: (B)

Starting with REST as the default API approach sets a solid, widely understood baseline. REST over HTTP emphasizes resource-based URLs, standard verbs (GET, POST, PUT, DELETE), stateless interactions, and clear status signaling. This makes APIs easy to cache, easy to test, and straightforward to scale horizontally, which is highly valuable in interviews when you’re outlining a design you can justify and reason about. REST also benefits from mature tooling, clear security and auditing patterns, and simple versioning strategies, all of which help you communicate a realistic, maintainable plan. You’d then justify extending beyond REST only when its limits block the required capabilities. GraphQL is worth reaching for if clients need highly customizable responses and you want to avoid over- or under-fetching data, especially when many clients with different needs are consuming the same API. It introduces a schema, query language, and potential caching tradeoffs, so it’s chosen when those advantages outweigh the added complexity. gRPC becomes attractive for internal services or performance-critical paths where you want fast, strongly-typed contracts, efficient serialization, and support for streaming or multiplexed calls. Server-Sent Events and WebSockets address real-time or streaming scenarios: SSE provides a simple, unidirectional server-to-client stream, while WebSockets enable full-duplex, low-latency communication suitable for chat, live updates, or collaborative features. So the best approach is to start with REST and only switch to GraphQL, gRPC, SSE, or WebSockets when REST cannot meet the needs of the system you’re designing.

Starting with REST as the default API approach sets a solid, widely understood baseline. REST over HTTP emphasizes resource-based URLs, standard verbs (GET, POST, PUT, DELETE), stateless interactions, and clear status signaling. This makes APIs easy to cache, easy to test, and straightforward to scale horizontally, which is highly valuable in interviews when you’re outlining a design you can justify and reason about. REST also benefits from mature tooling, clear security and auditing patterns, and simple versioning strategies, all of which help you communicate a realistic, maintainable plan.

You’d then justify extending beyond REST only when its limits block the required capabilities. GraphQL is worth reaching for if clients need highly customizable responses and you want to avoid over- or under-fetching data, especially when many clients with different needs are consuming the same API. It introduces a schema, query language, and potential caching tradeoffs, so it’s chosen when those advantages outweigh the added complexity. gRPC becomes attractive for internal services or performance-critical paths where you want fast, strongly-typed contracts, efficient serialization, and support for streaming or multiplexed calls. Server-Sent Events and WebSockets address real-time or streaming scenarios: SSE provides a simple, unidirectional server-to-client stream, while WebSockets enable full-duplex, low-latency communication suitable for chat, live updates, or collaborative features.

So the best approach is to start with REST and only switch to GraphQL, gRPC, SSE, or WebSockets when REST cannot meet the needs of the system you’re designing.