接受选择的 RESTful 方式

Question

我有一个简单的 api，它的工作原理是这样的:

用户创建一个请求 ( POST /requests )

另一个用户检索所有请求 ( GET /requests )

然后向请求添加报价 ( POST /requests/123/offers )

原始用户现在可以看到为请求所做的所有报价 ( GET /requests/123/offers )

我想要做的是允许初始用户接受请求，但我无法找出 RESTfuly 的最佳方法。

我应该用 PATCH 动词来做吗？赞 PATCH /requests/123并要求补丁正文包含有效的报价 ID？

Answer 1

接受一个提议五次应该与接受一次具有相同的效果。它是幂等的。所以它应该是一个PUT。

您可能需要考虑为您的“请求”选择一个不同的名称。当我执行 GET /requests/123 时，我请求的响应是请求吗？这对客户来说可能有点困惑。

此外，尽量避免嵌套资源标识符。这可能会在以后为您带来问题。要约并不一定要位于相应请求的“下方”。当您稍后想要与多个请求对应的报价时会发生什么？

A good rule of thumb is, if you would consider "Gizmo" an entity in an entity-relationship model, it should be a root-level URI, like in GET /gizmos/17, not GET /widgets/54/gizmos/17. A common mistake is to say "Every Gizmo has exactly one related Widget, so I should nest Gizmo URIs as extensions of Widget URIs."

下面我对操作的外观提出了建议。您可能想用 URI 替换某些 ID 引用，但这取决于您。

POST /requests            --->   201 Created
                                 Location: /requests/123

GET /requests             --->   200 OK
                                 [
                                     {
                                         "requestId": 123,
                                         "offersUri": "/offers?requestId=123",
                                         ...
                                     },
                                     ...
                                 ]

POST /offers              --->   201 Created
{                                Location: /offers/456
    "requestId": 123,
    "amount": 300,
    ...
}

GET /offers?requestId=123 --->   200 OK
                                 [
                                     {
                                         "requestId": 123,
                                         "amount": 300,
                                         ...
                                     }
                                 ]

PUT /offers/456/approval   --->  204 No Content
PUT /offers/456/approval   --->  204 No Content
PUT /offers/456/approval   --->  204 No Content