Question

由于某些原因，我的应用程序需要具有如下流程的API：

客户端调用服务器以获取新资源的ID。
然后用户花一点时间填写资源的表单。
然后用户点击保存（或不是......），当他通过写/myresource/{id}

设计这个的RESTful方式是什么？

第一个电话怎么样？在服务器端，这是生成ID并返回它的问题。它有副作用（递增序列，因此“保留空间”），但它没有明确地创建资源。

如果我理解正确，第3次调用应该是PUT，因为它会创建具有已知URI的内容。

Answer 1

你能做到的一种方法是：

客户POST空身到/myresource/
服务器回答，状态代码为302 (Found)，Location响应标头设置为/myresource/newresourceid（表示应该用于创建资源的ID / URI）
客户PUT一旦用户填写完表单，就会向/myresource/newresourceid添加新资源。

似乎足够RESTful。 ;）

Answer 2

我很想看到这个问题的其他答案，因为我想有很多方法可以做到这一点。

如果可能，我会让数据库中的自动递增ID作为您的代理键，并指定另一个字段作为您的业务标识符。它可能类似于产品代码或GUID。

考虑到这一点，客户端现在可以自己创建 ID ，这完全不需要第1步。他们会对/myresource/MLN5001或/myresource/3F2504E0-4F89-11D3-9A0C-0305E82C3301等网址进行PUT来创建资源。如果ID已在使用中，请在响应正文中返回带有冲突的409 Conflict。否则返回201 Created并在响应正文和位置标头中包含资源的URI。

Answer 3

我会选择

GET /myresource/new-id
POST /myresource/{id}

你的演练在动词上很清楚：

“GET [an]新资源的ID”

您可以将new-id重命名为您认为最清楚的内容。如果您有多个资源需要执行此操作，将生成器拆分为自己的资源可能会更好，例如

GET /id-generator/myresource
GET /id-generator/my-other-resource

如果有多种情况，用户将很快知道他们需要点击id-generator来获取他们的ID。如果它只是一个案例，那么他们只需要不经常使用它就很烦人。

我想你也可以做

GET /myresource-id-generator/next

看起来更清晰，但是如果你需要生成另一个ID，你必须制作另一个资源。

Answer 4

ID分配是非幂等的 - 分配操作的两次调用将获得不同的 ID - 因此应始终为POST。从那时起，资源应该在概念上存在。但是，我当时所做的就是用合理的默认值填充它（无论是执行POST还是PUT对整体设计的RESTful性来说都是无关紧要的），这样用户就可以花时间来改变它们他们希望他们想要的东西。

然后问题就变成是否应该有某种“释放这个;我完成了将其改为“最后的操作”。严格的RESTfulness说不应该，如果您知道资源标识符（URL），那么您可以谈论它。另一方面，这并不意味着托管服务器必须告诉其他任何人资源，直到创建用户满意为止;一般的HATEOAS原则没有说明其他人何时可以发现资源存在或知道名称是否允许您阅读该事物，但是在资源所有者开启之前拒绝向第三方表明资源存在是完全合理的“让这个公开”的旗帜。

RESTful方式来预分配ID

4 个答案: