Practice: Making a Booking Endpoint Safe to Retry

A hotel booking endpoint charges a card and reserves a room; add a key and say what each retry receives.

Making an endpoint safe to retry means choosing which requests carry a key and what each repeat receives. POST /bookings charges a deposit and reserves a room. It now requires an Idempotency-Key, stored per client for 24 hours with a fingerprint of the body. Say what each request receives.

The first request with key k1 succeeds, and the response is lost. The client retries with k1 and the same body.
The client retries with k1 while the first request is still charging the card.
A bug sends k1 again with a different room.
A client sends the booking with no key.
The client retries the first booking with k1 two days later.

Show the answers

Each retry and what the booking endpoint returns
Situation	Response	Effect
Lost response, retry with k1	The stored 201 and the same booking	One charge, one room
Retry while the first is running	409 Conflict	No second charge; retry later for the stored result
k1 with a different room	422 Unprocessable Content	Nothing booked; the bug surfaces
No key	400 Bad Request	Nothing booked
k1 two days later	A new 201 and a second booking	The window has passed, so it counts as new

The last row is why the window is documented. Twenty-four hours covers every automatic retry; a client holding a request for two days should check whether the first booking exists before sending it again.

← → move through sections and cards