爲什麼PATCH既不安全也不冪等？

我很難理解爲什麼PATCH在PUT不安全的地方。 Aso的冪等部分 - 如果我更新資源的字段，不會更新後該字段返回相同的值？爲什麼PATCH既不安全也不冪等？

2016-12-30 Tony Vincent

首先，PUT也不安全。

安全方法是不修改資源的HTTP方法。例如，在資源URL上使用GET或HEAD時，切勿改變資源。

由於PUT請求（因此PATCH爲此）更新資源，所以它不能被緩存，因此它不是安全的。

PUT雖然請求是冪等的，或者我應該說PUT請求應該是冪等的。

冪等HTTP方法是一種HTTP方法，可以多次調用而不會產生不同的結果。如果該方法僅被調用一次或十次以上，則無關緊要。結果應該是一樣的。同樣，這隻適用於結果，而不適用於資源本身。這仍然可以被操縱（如更新時間戳，只要該信息未在（當前）的資源表示共享。

後面PUT請求是冪等的想法是，如果在資源更新調用失敗，客戶端可以再次進行相同的呼叫，而不會導致任何不良或不一致的狀態。PUT請求始終應該在GET之前對資源發出請求，並且如果以後只有資源沒有更改，則應該成功。其中一個類似的答案 - Idempotent PUT request in concurrent environment

現在PATCH請求旨在更新只是選擇性的f ields，它不會獲得資源表示。因此，多次調用PATCH請求可能會導致資源狀態發生不希望的更改。因此它不是IDEMPOTENT。

例如： - 有資源Person

請求1： PATCH /人/ 1 { '年齡'：10} - 更新資源的年齡10

現在假設一些其他並行要求改變資源的狀態，說

請求2： PATCH /人/ 1 { '年齡'：19} - 更新資源歲至19

現在我f再次發送請求1，它將再次將資源時限更新爲10，因此導致不希望的結果。

雖然使用etags或If Modified Since標題，但它可以做成冪等。

來源

2016-12-30 06:14:31 hspandher

如果用戶發送的請求1之前，再次之後，爲什麼結果是不合需要的？我可以看到PUT的參數，因爲您必須提供所有屬性才能更改它，但對於PATCH，您只能將屬性限制爲您希望更新的屬性。（你是否也意味着「更新資源年齡再次10」？） – jt000

我已經修復了錯誤的建議，謝謝。從某種意義上說，這兩個請求都試圖在陳舊的假設上更新資源，這是不可取的。假設一個資源的初始值是7.由於該值是錯誤的，一個請求想要更新7到10，其他7到11，而不是10到11，反之亦然。 – hspandher

討論的有趣話題。我可以看到，對於用戶1更新年齡並試圖保留名稱而用戶2更新姓名並嘗試保持年齡的PUT。但對於PATCH他們明確地試圖更新年齡。似乎這兩個人只需要彼此身體對話來決定正確的值:)然而，我聽說過PATCH的一般性討論，聲稱它的不安全，因爲一些實現需要預設狀態（即https：//tools.ietf .org/html/rfc6902 - JSON PATCH的某些操作在這種情況下是不安全的）。 – jt000

PATCH更改資源屬性。更改可能需要屬性的具體的先前值，這使得它不具有冪等性。

From Name=John to Name=Gargantua.

然後重複應用名稱將是卡岡和補丁會失敗，因爲它需要新名稱爲「約翰」的轉變

"from Name=John"

來源

2018-02-14 08:10:59 Skip

爲什麼PATCH既不安全也不冪等？

回答

相關問題