我們只限於使用PUT方法來更新資源，所以PATCH不是一個選項（不幸的是）。REST API - 使用PUT方法去除屬性
上下文：有些字段映射到定義爲Optional和Editable的屬性上，這意味着用戶可以刪除先前輸入的和以前保存的值。
我的問題：哪個是通過PUT方法保存此更改的最佳選擇？ （去除從資源屬性）
AFAIK可有3個選項：
a）用一個空值，例如發送該屬性。 "invoiceSerial": ""
b）發送一個清零的屬性，例如： "invoiceSerial": null
三）不`噸在所有發送的屬性，在服務器端，應該從存儲對象中刪除他們
我不能老是發現處理所有失蹤編輯&可選屬性任何最佳實踐，所以任何暗示一些標準的文檔是值得讚賞的。
選項b看起來更好，比別人：
a）用一個空值，例如發送屬性。
"invoiceSerial": ""
如果invoiceSerial是一個數字怎麼辦？那麼你會發什麼？ 0？ 0對於給定的屬性是一個有效值會怎麼樣？
b）發送一個清零的屬性，例如。
"invoiceSerial": null
null是蠻好代表，以及，null值。
三）不`噸在所有發送的屬性，在服務器端，應該從存儲對象中刪除他們
這種方法看上去更復雜，無法處理所有丟失的編輯&可選屬性相比於選項b。
我不能找到任何最佳實踐，所以任何暗示某些標準文檔的讚賞。
我建議你先從RFC 7231
給定表示的成功PUT會建議對同一目標資源的後續GET將導致200發送的等價表示（OK ）的迴應。
如果你採取這個想法，並且向後工作，你可能會得到一個合理的答案。在刪除屬性後，資源的表現形式如何？
這可能意味着選擇（c）。
不`噸發送屬性可言，而在服務器端，應該從存儲的對象
消除他們處理所有失蹤編輯&可選屬性這裏的理由是，PUT有web publishing的語義。 「使用此URI使此文檔可用。」因此，您的目標是模仿支持Web創作的網站界面，將API客戶與您實施的細節隔離開來。
您可能還想查看Karl Dubost彙總的鏈接：Understanding HTTP PUT。