检查：重试不是新订单

保存预订后，服务器立即关闭连接而没有响应。客户知道什么？

• 由于连接错误，保存服务器预留也失败。
• 既然你写了请求，那么仓库预订肯定会成功。
• 由于尚未收到回复，工作结果尚未得到确认。
• 在重试之前删除现有预留是安全的。

如果我在每次重试时使用新的 UUID 作为幂等性密钥，会发生什么情况？

• 随着密钥变长，预订搜索结果的顺序会发生变化。
• 上一个请求的响应码从201变为200。
• 服务器更加严格地检查同一订单的数量冲突。
• 服务器可能会将重试视为新任务并进行重复保留。

同一个订单的数量发生了变化，我收到了409。这个实现应该怎么做？

• 停止重传，保留为拒绝状态，并维持现有保留
• 使用主体哈希作为新密钥重新安排更改数量。
• 使用 503 等等待策略重新发送文本最多四次。
• 猜测响应中的预订 ID，将其标记为已确认，然后完成。

处理后的密钥仅存储在进程内的集合中。哪种检查最能直接显示缺陷？

• 正常订单在同一流程中仅发送一次
• 重新启动服务器并将相同的输入再次发送到相同的分类帐
• 连续发送三种你从未见过的不同咒语。
• 检查是否在没有正常订单的情况下输入了错误的数量而被拒绝。

我从 POST 收到 201 和 ID，但 GET 查找仍然失败。什么样的记录符合合同？

• 留下已确认并在 POST 中收到的预订 ID。
• 休假被拒绝并新计算的预订 ID
• 保留未确认且空的预订 ID
• 保留已确认且空的预订 ID

仓库继续在每次 POST 时返回 503。这个练习的正确结局是什么？

• 每四次更改密钥并不断尝试直至成功。
• 第一个 503 被视为合同错误并被拒绝立即终止。
• 将四次失败转化为三次成功并记录下来
• 最多尝试四次，未经确认就停止。