我想知道我目前的方法是否有意义，或者是否有更好的方法。
我有多种情况，我想创建新对象并让服务器为这些对象分配一个 ID。发送 POST 请求似乎是最合适的方式。 然而，由于 POST 不是幂等的，请求可能会丢失，再次发送它可能会创建第二个对象。此外，由于 API 经常通过移动网络访问，因此丢失请求可能很常见。
因此，我决定将整个过程分为两步：
首先发送一个 POST 请求以创建一个新对象，该对象在 Location 标头中返回新对象的 URI。
第二次对提供的位置执行幂等 PUT 请求，以用数据填充新对象。如果新对象未在 24 小时内填充，服务器可能会通过某种批处理作业将其删除。
这听起来合理还是有更好的方法？
【问题讨论】：
标签： http rest post put idempotent
POST 创建优于 PUT 创建的唯一优势是服务器生成 ID。 我认为它不值得缺乏幂等性（然后需要删除重复项或空对象）。
相反，我会在 URL 中使用带有 UUID 的 PUT。由于 UUID 生成器，您是 nearly sure，您在客户端生成的 ID 在服务器端将是唯一的。
【讨论】：
这一切都取决于，首先你应该更多地谈论URI、资源和表示，而不是关心对象。
POST 方法是为非幂等请求或具有副作用的请求而设计的，但它can be used for idempotent requests。
关于表单数据的 POST 到 /some_collection/
normalize the natural key of your data (Eg. "lowercase" the Title field for a blog post)
calculate a suitable hash value (Eg. simplest case is your normalized field value)
lookup resource by hash value
if none then
generate a server identity, create resource
Respond => "201 Created", "Location": "/some_collection/<new_id>"
if found but no updates should be carried out due to app logic
Respond => 302 Found/Moved Temporarily or 303 See Other
(client will need to GET that resource which might include fields required for updates, like version_numbers)
if found but updates may occur
Respond => 307 Moved Temporarily, Location: /some_collection/<id>
(like a 302, but the client should use original http method and might do automatically)
一个合适的哈希函数可能像一些连接字段一样简单，或者对于大字段或值，可以使用截断的 md5 函数。详情见【哈希函数】2。
我假设你是：
【讨论】：
您在服务器、应用程序、专用请求响应中生成 id 的方法非常好！唯一性非常重要，但是客户，就像追求者一样，会不断重复请求，直到他们成功，或者直到他们愿意接受的失败（不太可能）。所以你需要从某个地方获得独特性，你只有两个选择。客户端，如 Aurélien 所建议的 GUID，或服务器，如您所建议的。我碰巧喜欢服务器选项。关系数据库中的种子列是一种现成的唯一性来源，冲突风险为零。 2000 年左右，我读到了一篇提倡这种解决方案的文章，名为“使用 HTTP 的简单可靠消息传递”，因此这是解决实际问题的既定方法。
阅读 REST 资料，您可能会认为一群青少年刚刚继承了猫王的豪宅。他们正在兴奋地讨论如何重新布置家具，他们对可能需要从家里带一些东西的想法感到歇斯底里。建议使用 POST，因为它在那里，而不是提出非幂等请求的问题。
在实践中，您可能会want to make sure all unsafe requests to your api are idempotent，除了身份生成请求的必要例外，正如您指出的那样，这并不重要。生成身份很便宜，未使用的身份很容易被丢弃。作为对 REST 的认可，请记住使用 POST 获取您的新身份，这样它就不会被缓存和到处重复。
关于the sterile debate about what idempotent means，我说它必须是一切。连续的请求应该不会产生额外的影响，并且应该收到与第一个处理的请求相同的响应。要实现这一点，您需要存储所有服务器响应，以便可以重放它们，并且您的 id 将识别操作，而不仅仅是资源。你会被赶出猫王的豪宅，但你会有一个防弹api。
【讨论】：
但是现在您有两个请求可能会丢失？ POST 仍然可以重复，创建另一个资源实例。不要想太多东西。只需让批处理过程寻找受骗者。可能有一些关于您的资源的“访问”计数统计信息，以查看哪些被欺骗的候选人是被放弃的帖子的结果。
另一种方法：根据一些日志筛选传入的 POST 以查看它是否是重复的。应该很容易找到：如果请求的正文内容与 x 前的请求的正文内容相同，则认为它是重复的。您可以检查额外的参数，例如原始 IP、相同的身份验证、...
【讨论】：
无论您使用哪种 HTTP 方法，理论上都不可能在不生成唯一标识符客户端、临时（作为某些请求检查系统的一部分）或作为永久服务器 id 的情况下发出幂等请求。丢失的 HTTP 请求不会产生重复，尽管有人担心请求可以成功到达服务器但响应不会返回到客户端。
如果最终客户端可以轻松删除重复项并且它们不会导致固有的数据冲突，那么开发一个临时的重复预防系统可能还不够大。对请求使用 POST 并将 HTTP 标头中的 201 状态和响应正文中服务器生成的唯一 ID 发送回客户端。如果您的数据显示重复经常发生或任何重复都会导致严重问题，我会使用 PUT 并在客户端创建唯一 id。使用客户端创建的 id 作为数据库 id - 在服务器上创建额外的唯一 id 没有任何好处。
【讨论】：
我认为您也可以将创建和更新请求合并为一个请求（upsert）。为了创建新资源，客户端 POST 一个“工厂”资源，例如位于 /factory-url-name。然后服务器返回新资源的 URI。
【讨论】：