目前正在開發一個 REST API，其中包含一組端點函式，用于更新特定資源的“狀態”。
我正在使用 POST 創建初始資源，然后使用 PUT 更新狀態 - PUT 是要使用的正確方法嗎？
狀態更新被記錄在日志中，因此為了避免有人多次更新具有相同值的狀態，我希望在其中放置一些業務邏輯，以避免相同狀態的兩個重復條目。如果有人嘗試兩次呼叫同一個函式，讓我們說“CancelResource()”——我應該在第二次呼叫時回傳 200 成功，而不是進行更新，還是發送某種錯誤回應會更好？
我正在考慮回傳 405“不允許的方法”，但這感覺有點苛刻。我也不知道 200 對客戶來說是否非常有用。
uj5u.com熱心網友回復：
PUT適合更新，并且PUT應該是冪等的。這意味著如果您連續兩次執行完全相同的PUT請求，則服務器狀態應該與您只執行一次時沒有什么不同。
這在例如不可靠的連接中很有用。如果請求失敗，客戶端可以重復請求，而不必擔心服務器會以某種方式接收并處理請求。
因此，如果您有辦法檢測到相同的請求，則忽略第二個并200 OK在兩者上都回傳 a，這是處理此問題的絕佳方法。
uj5u.com熱心網友回復：
PUT 是使用正確的方法嗎？
如果請求的主體被提議作為目標資源的替代表示，則 PUT 是合適的。
給定表示的成功 PUT 將表明對同一目標資源的后續 GET 將導致在 200（OK）回應中發送等效表示。-- RFC 9110
想想“保存檔案”——PUT 是我們嘗試將內容上傳到 Web 服務器時使用的 HTTP 方法。
我是否應該在第二次呼叫時回傳 200 成功，而不是進行更新，
大概。對于 2xx 與 4xx，您應該考慮狀態代碼對所涉及的快取的影響。請參閱RFC 9111。
請注意，RFC 9110 在討論If-Match條件標頭時特別提到了此選擇：
如果請求是一個狀態改變操作，似乎已經應用于選定的表示，源服務器可以用 2xx（成功）狀態代碼回應（即，用戶代理請求的改變已經成功，但是用戶代理可能沒有意識到這一點，可能是因為先前的回應丟失或其他用戶代理進行了等效更改）。
uj5u.com熱心網友回復：
PUT 是冪等的，拒絕 PUT 請求是沒有意義的，因為沒有任何改變。只需發送 200 ok，不要更改任何內容。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/528834.html
標籤：休息http-posthttp-状态码http-put
上一篇：基于相同的列值Sql創建列的排列