Practice this topic in a realistic system design interview
The shape of an API matters more than its URL format. It decides how clients ask for work, how servers return data, how errors are shown, and how the API can change over time.
An API architectural style is a common way to structure that communication. REST, GraphQL, gRPC, WebSocket, Server-Sent Events, webhooks, SOAP, and message-driven APIs all solve different kinds of problems.
A public product API needs predictable HTTP behavior, caching, and broad client support. A mobile screen may need one request that gathers data from many backend systems. A model-serving API may need strict request shapes, timeouts, and streaming tokens. A payment provider needs to notify another server after a charge settles.
No single style is best for all of those cases.
Good API design starts by asking, "What kind of communication is this?" Then you choose the style that fits. This chapter covers the major API styles and the tradeoffs that separate them.