API Styles: REST, gRPC, WebSockets, SSE

Every client-server API is one of a few conversation shapes, and picking the wrong one is a classic interview mistake. The animation runs four mini-panels side by side, each showing a phone talking to a server:

• REST: discrete volleys — the phone sends a request, the server sends one response, the connection is done. The right default for ~90% of client-facing APIs.
• Long-polling: the phone's request just hangs until the server has news, then the response fires and the phone immediately re-sends the request. Real-time updates faked with plain HTTP — the simple, infrastructure-friendly fallback.
• SSE (server-sent events): one request opens the tap, then a continuous downstream arrow of events flows server-to-phone. One-directional push: live scores, seat-map updates, notification feeds.
• WebSocket: one handshake, then arrows flowing both directions over a single persistent connection. True bidirectional traffic: chat, multiplayer games.

Watch how much heavier each shape is than the one before it. That is the decision tree: use the simplest shape that meets the requirement. The classic mid-level trap is proposing WebSockets for one-directional updates when SSE or polling would do — it signals reaching for the fancy tool instead of the right one. (A fifth style, gRPC, is not shown talking to the phone for a reason: browsers do not support it natively, so it lives between your internal services.)