HTTP方法POST是否必定是冪等的？

我陷入了與REST的理論問題。HTTP方法POST是否必定是冪等的？

想象一個簡單的產品庫存API。數據庫包含一個引用product，quantity和status的動作集合。

我有一個先決條件：我不希望API用戶操縱狀態。狀態值可以是reserved或confirmed。

首先，我想創建產品的預留。以下是相應的URL路徑和HTTP方法來表示：

[POST] /products/{product-id}/reservations

這創造了運動與狀態reserved並返回所創建的運動的ID。

現在，我想確認一下預約：

[POST] /reservations/{movement-id}/confirmations

在語義的方式，在我看來，我創建一個確認的預訂。事實上，我只是改變運動的狀態。

所以，2個問題：

我的第二個POST是冪等。我無法在RFC中找到這些信息，但POST可以是冪等的嗎？
您是否看到更好的方式來表示確認？

來源

2015-11-03 Gnucki

個人而言，我並不經常看到冪等的POST實現，因爲不應該像這樣使用此方法。冪等HTTP方法是一種HTTP方法，可以多次調用而不會產生不同的結果。如果你想堅持POST請求，只要確保多次調用不會改變結果，或者只是使用不同的方法，比如PUT來改變狀態，因爲它經常用於修改。 – Valdas

你說「不應該」。在RFC中，這是一個有意義的詞。你能給我一個確認的資源嗎？或者，我不認爲冪等性是關於結果的，而是關於服務器狀態的更多信息（在數據庫中創建了一個新的實體，...）。 – Gnucki

當談到POST請求時，規範說它不是冪等的。這意味着冪等性不能得到保證。但是，這並不意味着您需要確保多個'POST'請求不會產生與發出一個相同的結果。所以'POST' _may_可能是冪等的，但與'PUT'不同，規範並不能保證它。雖然'PUT'確實是一個更合適的選擇。 – Evert

我會使用PUT來代替。例如PUT /reservations/{movement-id}/status "confirmed"。

注：

不要緊，你的POST是冪等的，因爲你刪除鏈接的預訂確認後（HATEOAS），這樣的機會非常低，以至於2確認爲同一預訂到達。無論如何，我認爲PUT更合適。

來源

2015-11-03 15:04:32 inf3rno

感謝您的回答。當然，我認爲你的解決方案，但正如我在我的問題中所說的，我不希望API的用戶定義新的狀態。在你的解決方案中，狀態可以是用戶想要的任何東西。此外，我更喜歡API的更多語義使用。我沒有說我使用了一些超媒體系統，但問題更多的是：POST請求可以是冪等的還是不是？ – Gnucki

@Gnucki你應該驗證狀態。 POST通常不是冪等的，但是如果你願意，你可以使用它冪等的方式。至少我沒有在HTTP標準中發現任何限制，只是如果沒有新資源，則必須使用200或204而不是201。我不建議你用這種方式使用POST，這是一個例外，你沒有找到一個更好的HTTP方法，而不是一個規則。 – inf3rno

好的。感謝您的建議和搜索！ – Gnucki

HTTP方法POST是否必定是冪等的？

回答

相關問題