Question

第一种情况：

假设我在REST API中通过/customers和/customers/{id}端点提供了客户资源。

鉴于客户可以拥有多个地址，我基本上有三种选择：

添加/customers/{id}/addresses子集合端点。在这种情况下，我们可以 GET / POST / PUT / DELETE 到该端点获取/添加/修改/删除地址。
添加/addresses子集合端点。
不要创建其他端点，地址会在 GET /customers/{id}请求中返回，并且可以使用 PATCH 请求添加/修改/删除地址，例如。如果我们使用JSON-PATCH：
```
PATCH /customers/{id}

{
    "op": "add",
    "path": "/addresses/-",
    "value": /* new address */
}
```

对于“通用”API（即具有不同需求的多个不同客户的公共API），哪一个更合适？

第二种情况：

现在让我们考虑一个Document资源，它表示在多个用户之间共享的文档，例如Google Doc。每次用户开始编辑文档时，其ID都会添加到当前正在编辑该文档的用户列表中，例如：

GET /documents/{id}

{
    "data": /* ... */,
    "editors": ["userId1", "userId2"]
}

您是否会像上一个案例一样处理此问题？

选项＃1对我来说似乎不太自然，因为在这种情况下编辑器只是一个ID（内部，外键），我们可以考虑一个ID（更一般地说是一个简单的原始类型，如字符串，整数等）作为资源？此外，为每个“子资源”创建不同的端点将最终拥有大量端点，而 PATCH 选项（＃3）允许保留少量端点，同时另外提供此功能同时更新多个子资源，例如：

PATCH /documents/{id}

[
    {"op": "add", "path": "/editors/-", "value": "idUser"},
    {"op": "replace", "path": "/title", "value "new title"}
]

Answer 1

第一个选项。如果addresses属于客户，即不在不同客户之间共享（至少在一般情况下），我认为第一个选项适合REST方法，因为您将系统建模为集合资源和它们之间的等级关系。

您还可以将PATCH与第一个选项结合使用，以防您需要对地址进行部分更新（例如，如果您只需要修改街道的名称）

设计REST API：子集合和HTTP PATCH

1 个答案: