REST：防止通过条件POST创建重复资源？

Question

我一直在寻找最佳实践，以防止在使用POST创建新资源时意外创建重复资源，这是因为资源将由服务器命名，因此PUT无法使用。我正在构建的API将被移动客户端使用，我关心的情况是客户端在提交POST请求后但在获取响应之前断开连接。我发现this question，但没有提到使用条件POST，因此我的问题。

正在对父资源执行条件POST，类似于使用条件PUT修改资源，这个问题的合理解决方案？如果不是，为什么不呢？

客户机/服务器交互将是一样与条件PUT：

1. 客户端获取父资源，包括ETag的反映其当前状态（其中包括它的从属资源），

2. 客户端执行有条件POST父资源（包括在If-Match头父母的ETag值）来创建一个新的资源，

3. 客户端获取得到之前断开服务器响应，所以不知道它是否成功，

4. 之后，重新连接时，客户重新提交相同的条件POST请求，

5. 无论是早先的要求，没有达到服务器，因此服务器创建资源并用201回复，或者更早的请求确实到达服务器，所以服务器回复412并且不创建重复资源。

Answer 1

我觉得这个方案可行。如果你想确保POST不会导致重复，你需要客户端发送POST中唯一的东西。然后服务器可以验证唯一性。

您不妨让客户端为每个请求生成一个GUID，而不是通过GET从服务器获取该GUID。

你的步骤则变为： -

1. 客户端生成一个GUID
2. 客户端执行POST的资源，其中包括GUID
3. 客户端断开连接，不知道它是否成功
4. 客户端再次连接并执行具有相同GUID的另一个POST
5. 服务器检查GUID并创建资源（如果它从未收到第一个POST）或指示这是一个dupl icate

使用PUT可能更安宁，并让客户端决定资源名称。如果您不喜欢所选的名称，则可能表明您已创建了该资源，但它的典型位置是服务器选择的某个位置。

Answer 2

为什么不简单地使用服务器选择使用的任何内部机制在服务器上根据实际资源重复检测。

这只是更安全的方式。

然后您将URL返回到适当的资源（无论是否新创建）。

如果父母ETag是基于子资源的状态，那么它不是检查“重复资源”的可靠机制。你所知道的是，自上次以来，父母已经“改变”了。你甚至知道这是因为你的旧POST在断开连接后被处理了？ ETag可能会改变任何东西。

这基本上是一个乐观锁定情景正在播放，并且归结为另一个问题。如果资源已经创建，那么是什么？这是一个错误？还是一个功能？你关心？当资源已经存在时，发送服务器默认忽略的创建请求会不好吗？

如果它已经存在，但是“不同”足够（即说名称匹配但地址不同），是否是重复的？是更新吗？这是尝试更改现有资源的错误吗？

另一个解决方案是做两次旅行。一个来提出请求，另一个提交请求。如果请求中断，则可以查询请求的状态。如果提交没有完成，您可以再次提交。如果确实如此，你很高兴，可以继续前进。

只是取决于你的通信有多不稳定，以及这个特定的操作是多么重要，你是否想要跳过安全环来做这件事。

Answer 3

您的解决方案很聪明，但并不理想。您的客户可能永远无法获得他的201确认，并且必须将412错误解释为成功。

REST afficianados通常建议您使用空POST创建资源，然后，一旦客户端拥有新创建的资源的ID，他就可以执行“幂等”更新来填充它。这很好，但是你可能需要使数据库列可以为空，否则就不会这样，而且如果没有其他人试图同时更新，那么你的更新只会是幂等的。

据我说，HTTP是片状的。请求超时，浏览器窗口关闭，连接重新设置，列车与移动用户一起进入隧道。有一个简单，强大的模式来处理这个问题。不安全的操作应始终唯一标识，服务器应存储并能够在必要时重复对任何不安全请求的响应。这不是HTTP缓存，可以从缓存提供请求，但缓存可能因任何原因被刷新。这是服务器应用程序的保证，如果第二次看到“动作”请求，则存储的响应将被重复而没有其他任何事情发生。如果动作身份由服务器生成，那么请求 - 响应应该专用于发送该ID。如果你为一个不安全的请求实现这一点，那么你可以为所有人做这样的事情，这样做可以避免许多棘手的问题：连续的更新请求消除了其他用户的更改或者达到了不兼容的状态（“已经提交的订单“），连续删除请求产生404错误。

我有一个小小的谷歌文档探索更充分的模式if you're interested。