扩展单一 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) {

建议的一个选项是以逗号分隔的值作为stackexchange 的 answers-by-ids

/answers/{ids} GET 的用法

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

类似答案就是这种情况

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

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

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

这意味着 Id 将是一个 JSON 键，例如

[{

"id" : "1",

"name": "myAttribute"

"toggle": true

},

{

"id" : "2",

"name": "mySecondAttribute"

"toggle": false

}

]

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

预先感谢您的任何评论\答案

当前请求 VO

@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在您的RequestVODTO 本身中，而不是像您已经建议的那样保留在 URL 中，因为即使 URL 中有 100 个 id 也会使您的 URL 非常大，而您正在谈论 10K id。并且在未来，单个的比特长度id可能会增加，或者稍后您可能需要更新 50k 甚至 100K 的对象。根据URL 的最大长度，没有对 URL 长度的一般规范，但过长的 URL 通常是错误的，超过 2,000 个字符的 URL 在大多数流行的 Web 浏览器中将无法正常工作。所以我认为你的第二种方法在这里是最好的，并且对未来的目的也有好处。您可能还想使用PUT请求，因为它对更新请求更有意义。所以你的代码会变成这样：@PUT@Path("/update")@Produces(MediaType.APPLICATION_JSON)@Consumes(MediaType.APPLICATION_JSON)public ResponseVO updateBlockReason(List<RequestVo> requestVo) {

Answer 2

我发现路径product/{id}/update有问题，因为您可以通过映射@Put-request到product/{id}自身来实现类似的行为。READ、WRITE 区分已经通过请求映射明确显示。此外，是否在 restful url 中使用动词本身就是一个话题。假设您可以使用多个端点，这可能看起来像/products/{id}.因为你想批量/批量更新产品，你可以映射@Put-requests到/products现在，在 RequestBody 中有更新的产品列表。请记住，这会使响应变得有些复杂，因为您可能必须返回Http-207以回答列表中每个元素更新的正确状态。我想要 1 个逻辑端点进行更新您可以为此使用逻辑服务方法，但实际上没有端点。/{id}您已经提到了批量更新路径中的问题。如果你真的，真的需要，我会删除 -mapping@Put并/products/{id}重定向到/products更新内容将是单个元素列表的位置，或者更复杂一点，由 mediaType 区分（再次意味着两个端点，但单个 url ).编辑：我只是碰巧了解了 VO 问题。您不是在更新产品，而是在更新产品的一部分（名称 RequestVO 误导了我）。对我来说，这闻起来像@Patch-mapping一个产品的某些部分得到更新的地方。所以我仍然会使用/products但带有@Patch-mapping.当客户端需要完全替换现有资源时，他们可以使用 PUT。当他们进行部分更新时，他们可以使用 HTTP PATCH。这带来了另一个问题，@Post仅在 id 未知时使用（通常在创建某些内容并分配 id 之前，用于更新使用@Put和重用分配的 id）使用 post 在技术上是可行的，但由于idempotece不可取。

Answer 3

为什么不将请求正文中的 ID 列表作为 JSON 数组传递？代码将是：@POST@Path("/update/ids")@Produces(MediaType.APPLICATION_JSON)@Consumes(MediaType.APPLICATION_JSON)public ResponseVO updateBlockReason(@RequestBody List<Integer> ids, List<RequestVo> requestVo) {...}