RESTful方式接受选择

Jan*_*eks 5 rest

我有一个简单的api,就像这样:

  1. 用户创建请求(POST /requests)
  2. 另一个用户检索所有请求(GET /requests)
  3. 然后为请求添加商品(POST /requests/123/offers)
  4. 原始用户现在可以看到为请求所做的所有优惠(GET /requests/123/offers)

我想要做的是允许初始用户接受请求,但我无法找到最好的方法来执行它.

我应该用PATCH动词吗?喜欢PATCH /requests/123并要求补丁体包含有效的商品ID?

Tim*_*lds 7

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

您可能需要考虑为"请求"选择其他名称.当我这样做时GET /requests/123,我要求回复是一个请求?这对客户来说可能有点混乱.

此外,尽量避免嵌套资源标识符.这可能会在以后给你带来麻烦.要约并不一定要在相应的请求"下面".如果您以后想要提供与多个请求相对应的优惠,会发生什么?

一个好的经验法则是,如果你认为"Gizmo"是实体关系模型中的一个实体,那么它应该是一个根级别的URI,比如in GET /gizmos/17,not GET /widgets/54/gizmos/17.一个常见的错误是说"每个Gizmo都有一个相关的Widget,所以我应该将Gizmo URI嵌套为Widget URI的扩展."

下面我建议操作的外观.您可能希望用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
Run Code Online (Sandbox Code Playgroud)