Designing an API a front end will actually enjoy consuming

Most friction between back-end and front-end teams comes from APIs designed around database tables rather than around the screens they feed.

Shape responses around views, not tables

If a product card needs a name, a price, a thumbnail and a stock flag, there should be one request that returns exactly that. Forcing the client to call three endpoints and stitch the result is how you end up with slow pages and duplicated business logic in the browser.

Be boring about conventions

• Plural nouns for collections, identifiers for members.
• Filtering, sorting and pagination as query parameters — consistently named across every endpoint.
• HTTP status codes that mean what they say. A failed validation is 422, not 200 with an error body.
• One error format, everywhere, with a machine-readable code and a human-readable message.

Version before you need to

Adding a field is safe. Renaming or removing one is not. Put a version in the path from day one so the first breaking change is a routing decision rather than an emergency.

Make caching possible

Send ETag or Last-Modified on anything that is read far more than it is written, and be explicit in Cache-Control about what may be stored and for how long. An API that cannot be cached pushes load onto the database for no reason.

Document with examples

A schema tells you the shape. A worked request and response tells you how to use it. Ship both, and keep them in the repository next to the code so they go stale slowly.