我對標題Location和Content-Location.
內容位置
關于Content-Location我在規范中找到了這個宣告。（強調我的）
對于像 PUT（第 4.3.4 節）或 POST（第 4.3.3 節）這樣的狀態更改請求，它意味著服務器的回應包含該資源的新表示，從而將其與可能僅報告有關操作的表示區分開來（例如，“它成功了！”）。這允許創作應用程式更新其本地副本，而無需后續的 GET 請求。
但是，在 mdn 檔案中是一個顯示相反行為的示例。（強調我的）
該站點回傳一條通用成功訊息，確認該帖子已發布。服務器使用 Content-Location 指定新帖子的位置：
HTTP/1.1 201 Created Content-Type: text/plain; charset=utf-8 Content-Location: /my-first-blog-post ? Success!
這兩種說法似乎相互矛盾。
現在，我不確定是否應該在回應中不包括真實物體的情況下使用 Content-Location 。
地點
該規范有一個關于Location標題的句子。
對于 201（已創建）回應，位置值是指請求創建的主要資源。
mdn 也是這么說的。
在創建資源的情況下，它指示新創建資源的 URL。
我很困惑為不包含物體的帖子回復選擇哪一個。
我猜Location標題最適合以后可以查看物體的通用發布請求。例如，發布用戶并查看它。
帶有 202 代碼的 POST 回應呢？例如，將任務發布到佇列時，稍后只能查看任務的狀態。所以它不是像用戶這樣的真實物體。即根據發布的任務向 X 客戶發送了一封電子郵件，現在我想說明可以查看狀態（待定、失敗或成功）的位置。
uj5u.com熱心網友回復：
你是對的，MDN 對第一個例子是錯誤的。這個例子：
HTTP/1.1 201 Created
Content-Type: text/plain; charset=utf-8
Content-Location: /my-first-blog-post
? Success!
提示 的內容/my-first-blog-post 是 ? Success!，由于Content-Location標頭。
既然你不希望回傳新資源的身體，你應該保持Location并忽略Content-Location。
如果你有時間：向 MDN 維護人員報告問題。
帶有 202 代碼的 POST 回應呢？例如，將任務發布到佇列時，稍后只能查看任務的狀態。所以它不是像用戶這樣的真實物體。即根據發布的任務向 X 客戶發送了一封電子郵件，現在我想說明可以查看狀態（待定、失敗或成功）的位置。
我會建議一個Link標題。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/407045.html
標籤：