我有一個 ID REST API，我需要對其進行擴展以支持多個（最多 10Ks）ID?；旧鲜菍λ邢嚓P 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@NoArgsConstructorpublic class RequestVO { private String name; private boolean toggle; // will add now private int id }我還擔心，如果我想（要求之一）使用相同的請求（如 name=doA，toggle=true）更新 10Ks ID，我將不得不復制請求 VO 而不是單獨發送 ID
3 回答
紫衣仙女
TA貢獻1839條經驗 獲得超15個贊
最好的方法是保留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) {
慕勒3428872
TA貢獻1848條經驗 獲得超6個贊
我發現路徑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不可取。
手掌心
TA貢獻1942條經驗 獲得超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) {
...
}
添加回答
舉報
0/150
提交
取消