What the interviewer is checking
- Coverage, from the client’s view
- Who may touch which object
- Paging, safe retries, slow work
- Five minutes, not fifteen
Send userId in the body?
Bad: userId in the body
The client controls the body, so anyone can book as anyone.
Good: User from the token
Plus an ownership check on every object it names.
The details that separate strong answers
Identity from the token, a cursor on every list, an Idempotency-Key on writes that cost money, and 202 for slow work.
A lost reply, a safe retry
The booking commits but the reply is lost. The app retries with the same Idempotency-Key and gets the same booking back, not a second charge.
A seller’s 50,000-row catalogue import takes minutes. Hold the request open?
The answer
No. Return 202 with a status URL, run it on workers, and let the seller poll with Retry-After or get a webhook.
Photo bytes never touch the API
The API hands out a short-lived pre-signed URL, and the app PUTs the photo straight to storage. Base64 in JSON would turn 4 MB into 5.3 MB.
5×
slower home screen from five sequential calls
At 100 ms a mobile round trip, five calls cost 500 ms before anything renders. One aggregate call, such as GET /v1/home, costs about 100 ms.
Say it like this
One endpoint per requirement, REST and JSON for the apps. The user comes from the token, lists take a cursor, money-moving writes take an Idempotency-Key, and slow work returns 202.