REST API

REST organizes an API around nouns, not verbs. Things get URLs (/users, /users/42, /users/42/orders) and HTTP methods say what you are doing to them: GET to read, POST to create, PATCH to edit, DELETE to remove. Bodies and responses are almost always JSON. If you have used the GitHub or Stripe API, you have used REST.

It is the default choice for a reason: every language, browser, proxy, and CDN already speaks HTTP, so you inherit ready-made caching, status, and retry semantics instead of inventing them. Inherit, not get for free: a response is only cacheable if you pick the right method and set the right headers, and retries only happen if the client is told when they are safe. Reach for GraphQL instead when clients need wildly different field selections from one round trip, and for gRPC when you control both ends and want speed over readability.

Misconception worth clearing: almost nothing labeled REST is REST in Roy Fielding's original sense (that version expects clients to navigate the API through hypermedia controls the server hands them, rather than hardcoding URLs, which practically nobody ships). In practice 'REST API' means 'JSON over HTTP with sensible URLs'. The real trap is inconsistency: mixing /getUser with /users, returning 200 with an error body, or changing a field's shape without versioning. Pick conventions on day one and keep them.