我們是否應該始終在HTTP PUT請求中驗證url和body中的資源ID？

假設我更新的員工記錄我們是否應該始終在HTTP PUT請求中驗證url和body中的資源ID？

網址 - /api/employees/10

體 -

{ 
    id : 10, 
    name : xyz 
}

我應該驗證在URL中的員工ID是一樣的反應呢？由於一名員工可以自己點擊網址，但通過在PUT正文中發送另一個值來更新另一名員工的數據。

來源

2013-04-07 Sanjeev Kumar Dangi

聽起來像你已經回答了你自己的問題。如果你不信任用戶，他們可以以你不想要的方式使用你的系統，那麼**是**驗證！ – 2013-04-07 09:02:46

但是，如果這是一般情況，那麼首先應該永遠不允許在PUT請求中使用IDS。爲什麼複製數據和驗證？ – 2013-04-07 09:09:30

如果您必須驗證，那麼您可能希望使用POST。 POST不是冪等的，你應該管理這個變化。

PUT是冪等的，它只是創建一個資源。這意味着你實際上並不關心什麼是id 10，以及它是一個新的id還是一個現有的id。您只需使用您提供的資源替換ID 10。你只有在知道uri應該是什麼時才使用PUT。

來源

2013-05-11 10:22:56 Andy

我完全不同意。 PUT用於當您想要更新（創建新的*或*替換現有的）位於URI的資源。當您想要告訴該資源執行某些操作時，POST是用於。聽起來PUT非常適合OP的用例。當使用PUT時，服務器當然可以*應該*驗證用戶試圖放置的對象是否合理並且可以接受：格式正確，是否自我一致，是否違反其他對象的約束，等等... – Celada 2013-05-11 10:57:35

是的，如果對象在表體中包含自己的鍵，則應驗證它是否與URL中的鍵匹配。對於客戶端來說，嘗試在/api/employees/10上放置一個對於員工＃10的記錄不是有效值的對象時出錯，因此應該檢查該對象並將其報告爲錯誤，就像檢查對象是否具有正確的語法。

我相信在這種情況下返回的最佳錯誤代碼是422 Unprocessable Entity，但我可能是錯誤的。

你可以做的另一件事是在身體中不要包含任何鑰匙。然而，我發現保持關鍵是與API的其他部分（可能嵌入其他對象內部）表示同一類型的對象的方式保持一致。使用XML時尤其如此（儘管看起來您在這裏使用JSON）。

來源

2013-05-11 11:08:20 Celada

我們是否應該始終在HTTP PUT請求中驗證url和body中的資源ID？

回答

相關問題