Exercício prático · REST / HTTP

Practice lab: Retry after a response is lost

do caderno de estudos · atualizado em 2 de outubro de 2026
Para quem vai encarar entrevista de REST / HTTP2 min

Tente resolver a tarefa antes de consultar os critérios. Compare o resultado e explique o que mudou no seu raciocínio.

Tarefa e critérios de verificação

Task, 15 minutes: design POST /orders for a client that times out after the order commits. Specify the request payload, idempotency key scope, persisted state, and retry response. Draw the timeline for two concurrent requests sharing a key.

Check your work:

  • Both identical requests refer to one logical order. An atomic claim prevents duplicate creation.
  • Reusing the same key with a different payload is rejected according to the documented contract. Another caller cannot fetch the first caller's result.
  • A crash after commit but before response delivery leaves enough durable information for the retry to recover the original outcome.
  • State how long keys are retained and what a retry after expiry means. A key is not an unlimited exactly-once guarantee.

Follow-up: explain why DELETE can return 204 and then 404 without violating idempotency. Distinguish repeated server effect from repeated response bytes.

No app, a tarefa fica visível e você pode revelar os critérios depois da tentativa. Use as notas para registrar sua solução.

Praticar este exercício no app