Stop 20 · Interview PreparationTechnical · 5/8

API design

Part of the Full Stack Developer Roadmap

In short

"Design the API for a restaurant menu and orders." This question tests whether a frontend developer would enjoy using your API, and whether it survives version two.

Being fluent in designing APIs that are pleasant for a frontend to consume — endpoint structure, status codes, and avoiding overly chatty request patterns.

The purple blob proudly holds open a big picture menu with neat sections of dishes.

Think of it like this

A good restaurant menu card

A clear menu has sections, the same layout for every dish, prices in one format and notes like 'sold out'. You never need to ask the waiter how to read it. An API should feel that obvious to the frontend.

Watch it happen

Answering an API design question

Resources

Endpoints

Shapes

Errors

Pagination

Versioning

1/6Name the nouns: restaurants, menu items, carts, orders. Plural, lowercase, no verbs.

The big ideas

What you need to know

Design from the screen

Ask what the menu screen shows and return it in one call, instead of making the app stitch five calls together.

Be boringly consistent

Same naming, same list shape, same error shape everywhere. Consistency beats cleverness.

Safe to retry

GET, PUT and DELETE should be idempotent. For POST /orders, accept an Idempotency-Key so a retry doesn't order twice.

Auth and limits

Say how clients authenticate, what each role may call, and how you rate limit.

See it in code

Walk through the code

http

1GET /v1/restaurants/42/menu?category=starters&limit=20&cursor=eyJpZCI6ODh92Authorization: Bearer <token>3 4HTTP/1.1 200 OK5Content-Type: application/json6 7{8  "data": [{ "id": "m_91", "name": "Paneer Tikka", "pricePaise": 24900, "veg": true }],9  "nextCursor": "eyJpZCI6MTA5fQ"10}11 12POST /v1/orders   ->   422 Unprocessable Content13{ "error": { "code": "ITEM_UNAVAILABLE", "message": "Paneer Tikka is sold out", "field": "items[0]" } }