POST不是幂等的后果（RESTful API） [英] Consequences of POST not being idempotent (RESTful API)

问题描述

我想知道我当前的方法是否有意义或是否有更好的方法。

I am wondering if my current approach makes sense or if there is a better way to do it.

我有多种情况我想创建新对象和让服务器为这些对象分配ID。发送POST请求似乎是最合适的方法。
但是，由于POST不是幂等的，请求可能会丢失并再次发送可能会创建第二个对象。由于API经常通过移动网络访问，因此丢失请求可能非常常见。

I have multiple situations where i want to create new objects and let the server assign an ID to those objects. Sending a POST request appears to be the most appropriate way to do that. However since POST is not idempotent the request may get lost and sending it again may create a second object. Also requests being lost might be quite common since the API is often accessed through mobile networks.

因此，我决定将整个过程分为两个步骤。
首先发送POST请求以创建新对象，该对象返回Location头中新对象的URI。其次，对提供的位置执行幂等PUT请求，以使用数据填充新对象。如果未在24小时内填充新对象，服务器可能会通过某种批处理作业将其删除。

As a result i decided to split the whole thing into a two-step process. First sending a POST request to create a new object which returns the URI of the new object in the Location header. Secondly performing an idempotent PUT request to the supplied Location to populate the new object with data. If a new object is not populated within 24 hours the server may delete it through some kind of batch job.

这听起来合理还是有更好的方法？

Does that sound reasonable or is there a better approach?

谢谢

推荐答案

POST创建优于PUT创建的唯一优势是服务器生成的ID。
我不认为缺乏幂等性（然后需要删除重复项或空对象）。

The only advantage of POST-creation over PUT-creation is the server generation of IDs. I don't think it worths the lack of idempotency (and then the need for removing duplicates or empty objets).

相反，我会使用PUT在URL中使用 UUID 。由于UUID生成器，您几乎可以确定您生成客户端的ID将是唯一的服务器端。

Instead, I would use a PUT with a UUID in the URL. Owing to UUID generators you are nearly sure that the ID you generate client-side will be unique server-side.

这篇关于POST不是幂等的后果（RESTful API）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！