大輸入數據的REST端點（GET）

Question

我正在開發一個應用程序，我需要將對象列表傳遞給REST端點，REST端點將執行一些計算並將結果返回給調用者。

問題更多地是關於如何處理這種情況的哲學問題？

在GET請求中傳遞巨大的負載是一個壞主意。同時它不是一個真正的POST/PUT請求，因爲它不會修改服務器上的任何狀態。

有沒有人遇到過這個？

Answer 1

這個問題更多地是關於如何處理這種情況的哲學問題？網絡的理念

的是，你不應該需要知道端點是如何實現的：與答案文檔預先計算VS上飛VS重定向到其他人的計算。

所以從純哲學的角度來看，GET是正確的答案。

GET不支持內容正文;您唯一的選擇就是將此特定計算的結果表示爲資源 - 換句話說，將您的數據存入URI。

實際上，您可能會遇到arbitrary limits URI的長度可能有多長。所以根據客戶端（瀏覽器/庫），這可能是一個問題。

PUT會很好;與POST相比，它的優勢在於PUT應該是冪等的，使用PUT通過統一接口傳遞所需的丟失消息語義。

不幸的是，PUT規範要求使用消息有效載荷的目標資源的替換。這實際上是關於文件傳輸。也就是說，RFC-7231確實會給你一些迴旋餘地。

當PUT表示是與目標資源不一致，源服務器應該或者使它們一致，通過變換表示或改變資源的配置，或用含有足夠的信息以適當的錯誤消息來響應解釋爲什麼表示是不合適的。

所以你可能會爭辯說，計算的結果是表示的轉換。

這種使用PUT並非真正與Jim Webber談論的不同。在RESTbucks演示中，您可以通過PUT方法在系統中創建訂單來觸發業務域中的副作用，並創建一個用於跟蹤訂單狀態的資源。

在這種方法中，每個提交的計算應該有一個唯一的標識符;你將PUT輸入到這個計算中，它會返回一個201 - Created，結果。理論上，您可以在資源上支持GET，在不需要輸入的情況下返回結果，或者在資源上使用DELETE，作爲客戶端已經收到計算結果並且不需要服務器上的任何確認更長的時間。

不是 - 你並不需要它，你當然也不需要在每個資源上都支持所有的http方法。

如果這種方法是不可接受的（例如，如果您使用HTML作爲您的媒體類型），POST是您不可或缺的方法。它並不適合你想要的東西;但POST必須支持非冪等操作，這意味着統一接口不會識別您的計算是冪等的。在快樂的道路上這不是什麼大不了的事情。