Question

我有一个简单的api，就像这样：

用户创建请求（POST /requests）
另一位用户检索所有请求（GET /requests）
然后向请求添加商品（POST /requests/123/offers）
原始用户现在可以看到针对请求的所有优惠（GET /requests/123/offers）

我想做的是允许初始用户接受请求，但我无法找到最好的方法来实现它。

我应该用PATCH动词吗？与PATCH /requests/123类似，并要求补丁正文包含有效的商品ID？

Answer 1

接受报价五次应该与接受一次报价相同。它是幂等的。所以它应该是一个PUT。

您可能需要考虑为＆＃34;请求选择其他名称。＆＃34;当我GET /requests/123时，我请求一个请求的响应？这对客户来说可能有点混乱。

此外，尽量避免嵌套资源标识符。这可能会在以后给你带来麻烦。要约并不是真的必须在＆＃34;下面＆＃34;相应的要求。如果您以后想要提供与多个请求相对应的优惠，会发生什么？

一个好的经验法则是，如果你考虑＆＃34; Gizmo＆＃34; entity-relationship model中的实体，它应该是根级别的URI，例如GET /gizmos/17，而不是GET /widgets/54/gizmos/17。一个常见的错误是说＆＃34;每个Gizmo都有一个相关的Widget，所以我应该将Gizmo URI嵌套为Widget URI的扩展。＆＃34;

下面我建议操作的外观。您可能希望将某些ID引用替换为URI，但这取决于您。

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

Answer 2

取决于接受的性质。

如果Acceptance是商品的简单属性，我会在Offerance设置为True的情况下发布商品。

如果接受更加复杂，因此本身就是一种资源，我会接受要约（PUT /requests/123/offers/acceptance）。

如果存在拒绝或要约澄清请求，我可能会认为相关资源是响应，而不是接受，并且PUT（put /requests/123/offers/response）。

RESTful方式接受选择

2 个答案: