REST, GraphQL, and WebSockets

01Explain it simply

REST models an API as resources addressed by URLs and manipulated with HTTP methods. GraphQL models an API as a typed schema the client queries for exactly the fields it needs in one request. WebSockets open a persistent bidirectional connection for continuous real-time updates instead of the client repeatedly asking.

One-line definition: Match an API style to the actual data-fetching and real-time shape of the problem.

02Mental model

Think about the shape of the problem: REST fits resource-oriented CRUD where HTTP caching and simplicity matter; GraphQL fits UIs that need to compose data from many underlying sources without over- or under-fetching; WebSockets or SSE fit when the server needs to push updates without being asked.

03Step by step

• Identify whether the client needs a stable resource shape (REST) or a flexible per-screen shape (GraphQL).
• Check whether HTTP-layer caching is important — REST benefits directly, GraphQL usually needs its own caching layer.
• Determine whether updates must be pushed continuously, which rules out plain request/response.
• Choose SSE for one-way server push, WebSockets for bidirectional real-time.
• Consider that these approaches can coexist in the same system for different concerns.

04Working example

1// REST: resource + method2GET /api/orders/423
4// GraphQL: client-shaped query, one round trip5query { order(id: 42) { id total items { name price } } }6
7// WebSocket: persistent channel, server can push anytime8const socket = new WebSocket('wss://api.example.com/orders/42/updates');9socket.onmessage = (event) => updateOrder(JSON.parse(event.data));

The REST call returns whatever shape /orders/42 is defined to return. The GraphQL query lets the client ask for exactly items.name and items.price without a second request. The WebSocket stays open so the server can push an update the moment the order changes, with no polling.

05Where it is used

• REST for public APIs, resource-oriented CRUD, and CDN-cacheable reads
• GraphQL for dashboards composing many nested data sources per screen
• WebSockets for chat, live collaboration, and trading tickers
• SSE for one-way live feeds like notifications or progress updates

06Common mistakes

• Adding GraphQL to avoid over-fetching on a simple CRUD API that didn't have that problem
• Polling REST endpoints every second instead of using a push mechanism for real-time data
• Assuming GraphQL is automatically cacheable the way GET REST responses are
• Using a WebSocket when data only flows client-to-server occasionally, where plain requests are simpler

07Interview answer

Justify the choice by over/under-fetching, caching needs, and push-vs-pull — not by declaring one approach universally 'modern' or 'better.'