扩展 Single ID REST 端点以支持多个 ID

Question

我有一个 ID REST API，我需要扩展它以支持多个（最多 10Ks）ID。基本上是在所有相关 ID 上运行更新，而不是在网络中发送 10Ks 请求。

当前端点：

@POST
@Path("{id}/update")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public ResponseVO updateBlockReason(@PathParam("id") int id, List<RequestVo> requestVo) {

一个选项suggested 是stackexchange's answers-by-ids 的逗号分隔值

/answers/{ids} GET 的使用

{ids} 最多可以包含 100 个分号分隔的 id。要以编程方式查找 id，请在 answer 对象上查找 answer_id。

similar answers就是这种情况

http://our.api.com/Product/<id1>,<id2> ：正如詹姆斯建议的那样，可以选择，因为产品标签后面的内容是一个参数

但这对我来说似乎很尴尬，RequestVo 对于所有 ID 都是相同的（目前很好，但以后添加这样的支持会更难）

看来我需要从 Path 变量中更改以将其添加到 RequestVO 中

这意味着 Id 将是 JSON 密钥，例如

[{
"id" : "1",
"name": "myAttribute"
"toggle": true
},
{
"id" : "2",
"name": "mySecondAttribute"
"toggle": false
}
]

这是正确的方法还是我遗漏了什么？

提前感谢您提供任何 cmets\answers

当前请求语音

@Data
@AllArgsConstructor
@NoArgsConstructor
public class RequestVO {

 private String name;
 private boolean toggle;
 // will add now private int id
 }

我还担心，如果我想（其中一项要求）使用相同的请求（如 name=doA，toggle=true）更新 10Ks Id，我将不得不复制请求 VO 而不是单独发送 ID

Answer 1

最好的方法是将 id 保留在您的 RequestVO DTO 本身中，而不是像您已经建议的那样保留在 URL 中，因为即使 URL 中的 100 个 id 也会使您的 URL 变得非常大，而您正在谈论 10K id。

同样，在未来，单个id 的位长可能会增加或稍后您可能需要更新 50k 甚至 100K 对象。

根据maximum length of a URL，没有关于 URL 长度的通用规范，但极长的 URL 通常是错误的，超过 2,000 个字符的 URL 在最流行的网络浏览器中无法使用。

所以我认为你的第二种方法在这里最好，并且对未来的目的也有好处。

您可能还想使用PUT 请求，因为它对更新请求更有意义。所以你的代码会变成这样：

@PUT
@Path("/update")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public ResponseVO updateBlockReason(List<RequestVo> requestVo) {

Answer 2

为什么不将请求正文中的 ID 列表作为 JSON 数组传递？代码是：

@POST
@Path("/update/ids")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public ResponseVO updateBlockReason(@RequestBody List<Integer> ids, List<RequestVo> requestVo) {
...
}

Answer 3

我发现路径 product/{id}/update 有问题，因为您可以通过将 @Put-request 映射到 product/{id} 本身来实现类似的行为。 Request-mapping 已经明确了 READ、WRITE 的区别。 另外，是否在 restful url 中使用动词本身就是一个话题。

假设您可以使用多个端点，这可能看起来像 /products/{id}。

因为您想批量/批量更新产品，您现在可以将@Put-requests 映射到/products，并在 RequestBody 中包含更新的产品列表。请记住，这会使响应变得有些复杂，因为您可能必须返回 Http-207 才能回答列表中每个元素的正确更新状态。

我想要 1 个逻辑端点进行更新

您可以为此使用逻辑服务方法，但实际上没有端点。 您已经在批量更新的路径中提到了/{id} 的问题。 如果你真的真的需要，我会从/products/{id} 中删除@Put-mapping 并重定向到/products，其中更新内容将是单个元素列表，或者更复杂一点，由 mediaType 区分（什么再次表示两个端点，但是一个 url）。

编辑： 我只是碰巧理解了VO问题。您不是在更新产品，而是更新其中的一部分（RequestVO 这个名字误导了我）。 对我来说，这闻起来像 @Patch-mapping，其中部分产品会得到更新。 所以我仍然会使用/products，但使用@Patch-mapping。

当客户端需要完全替换现有资源时，他们可以使用 PUT。当他们进行部分更新时，他们可以使用 HTTP PATCH。

这带来了另一个问题，只有在 id 未知时才使用@Post（通常在创建某些东西并获得分配的 id 之前，对于更新使用 @Put 并重用分配的 id） 使用 post 在技术上是可行的，但由于 idempotece 不建议使用。