通過REST服務批處理

Question

是否有通過REST爲POST，PUT，PATCH動詞執行BATCH操作的最佳實踐？

我下面當前範例是，JSON有效載荷在所述主體中指定的所有3個操作

一個）POST返回創建的資源
B的位置）PUT/PATCH返回201，如果更新成功

對於批處理操作，我打算接受有效內容主體中的json對象的集合，但正試圖確定要返回給客戶端的內容。 在處理批處理時，操作可能會成功執行某些項目，但可能會失敗。

考慮到這一點，我認爲最好的做法是從有效負載中返回指示每個 項目的成功/失敗狀態的對象集合。

但是，這偏離了上面（a）和（b）中概述的範例。

相反，它是否有意義將代表批處理操作本身的ID的標識符返回給客戶端？

然後客戶端會發出一個後續的GET來獲取它所請求的操作的結果。

這種方法聽起來合理嗎？如果是這樣，如果操作沒有完成，在後續GET上阻止客戶端是否合理？或者總是返回最新狀態，即客戶端請求處理的每個項目的響應集合是否合理。

想法/想法/建議？

由於REST是一種體系結構風格，不一定有明確的「準則」，並且沒有關於如何實現HTTP動作的操作的要求，所以顯然這裏沒有正確或錯誤的答案。

我在尋找優雅，自然，直觀的解決方案。

Answer 1

REST是一種建築風格。

我實現API以始終返回更新結果。所以在POST的情況下，它將返回創建的實體，使用PATCH和PUT它將返回更新的實體。

根據批量大小，我將返回處理內容的數組，或者處理內容的標識符數組。

如果批處理操作是長時間運行的返回標識批次，但要明確痛苦的終點是從其他端點

前夫不一樣。如果您通過張貼到 http://somesite.com/users

發送一批請求 http://somesite.com/batch/users

上創建一個用戶得到返回批量操作的狀態，同時它仍在運行，在完成返回記錄的數組被更新的。

最重要的是一致性，無論您選擇什麼，始終遵循相同的方法，在整個系統中進行批量操作。

Answer 2

從外部看，REST操作應該是原子的。也就是說，如果請求的一部分失敗，那麼服務器的整個狀態應該恢復到預先請求狀態，並返回一個4xx或5xx響應（例如，如果請求可以重複，整個過程沒有不良影響，如果它第一次失敗了）。然而，這與批量操作本身無關 - 這樣的請求可能是任何類型的請求。

批處理操作違反了統一接口（由HTTP的方法及其對指定URL處的資源的操作定義）的不同REST約束。

如果您想要執行批處理操作，請放棄嘗試調用您的API RESTful，因爲您已經失去了REST賦予的好處，並且只是對自己說謊。

如果您想保留這些好處，請放棄批量操作。