![](/img/trans.png)
[英]How to pass api ID and api Key as authentication parameters of HTTP request
[英]Can we pass parameters to HTTP DELETE api
我有一個 API 將刪除一個資源 (DELETE /resources/{resourceId})
上面的 API 只能告訴我們刪除資源。 現在我想將 API 擴展為其他用例,例如在刪除或刪除此資源的其他依賴資源之前備份該資源等。我想將刪除 API 擴展到此 (DELETE /resources/{resourceId}?backupBeforeDelete=真的...)
上述擴展 API 好/推薦嗎?
根據HTTP 規范,任何 HTTP 消息都可以帶有可選的正文和/或 header 部分,這意味着執行您的操作(例如,您可以在后端控制和常規接收什么)在任何 HTTP 方法的情況下; 但是,如果您在談論RESTful API設計、DELETE 或任何其他操作,則應參考 REST API 基於端點資源的方法邏輯,然后在您的方法中執行操作,然后在您的方法中執行操作。
DELETE /resources/{resourceId} HTTP/1.1
應該可以。
上述擴展 API 好/推薦嗎?
可能不是。
HTTP 是(除其他外)關於消息語義的協議:關於消息含義的統一協議。
基本目標是,由於每個人對消息的含義都有相同的理解,我們可以使用許多通用組件(瀏覽器、反向代理等)。
當我們開始嘗試以非標准方式處理消息時,我們就失去了通用接口的好處。
就 DELETE 而言,您的用例遇到了一個問題,即 HTTP 沒有定義參數化的 DELETE。
在 HTTP 消息中放置參數的通常位置是在消息正文中。 很遺憾...
DELETE 請求消息中的有效負載沒有定義的語義; 在 DELETE 請求上發送有效負載正文可能會導致某些現有實現拒絕該請求
換句話說,您不能指望通用組件在這里做正確的事情,因為請求正文超出了范圍。
另一方面
DELETE /resources/{resourceId}?backupBeforeDelete=true
這存在通用組件無法識別/resources/{resourceId}?backupBeforeDelete=true
是與/resources/{resourceId}
相同的資源的問題。 兩者的標識符不同,發送給其中一個的消息不會影響另一個。
對於您的用例,正確的答案是更改您的方法令牌; 您在這里嘗試執行的正確標准方法是 POST
POST 在 HTTP 中有許多有用的用途,包括“此操作不值得標准化”的一般用途。 ——菲爾丁,2009
您應該使用資源的“真實”URI(與 GET 請求中使用的相同),並將您需要的任何參數粘貼到有效負載中。
POST /resources/{resourceId}
backupBeforeDelete=true
假設您將 POST 用於其他“不值得標准化”的操作,則請求中需要有足夠的上下文,以便服務器可以區分不同的用例。 在 web 上,我們通常會通過 HTML 表單收集參數,通常的答案是在正文中包含請求令牌
POST /resources/{resourceId}
action=delete&backupBeforeDelete=true
另一方面,如果你認為你正在做一個值得標准化的動作,那么正確的做法是定義一個具有你想要的語義的新方法標記,並推動采用
MAGIC_NEW_DELETE /resources/{resourceId}
backupBeforeDelete=true
畢竟,這是PATCH的來源; Dusseault 等人認識到補丁語義可能對所有資源都有用,創建了一個描述他們想要的語義的文檔,並通過標准化過程引導了該文檔。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.