如何正確發送406狀態碼？

我正在開發一個RESTful API服務，最初只會接受和響應JSON格式。我想遵循標準，並在請求者的情況下接受標題不同於JSON我想用406 HTTP狀態代碼進行響應以通知請求者我無法以其他格式輸出數據。如何正確發送406狀態碼？

根據W3我「應該包括含有可用的實體特徵和位置（S），用戶從該用戶或代理可以選擇一個最合適的列表的實體」在我的響應。

我該怎麼做，因爲上面的解釋沒有告訴我很多。什麼是實體？

任何意見/建議？

編輯

起初我想，也許可以在內容類型頭一個逗號分隔的列表，但也許重新考慮後，我應該做同樣的事情瀏覽器做的，使用接受頭？這實際上更有意義，但我找不到任何信息來支持這一點。

來源

2010-12-12 Michal M

三個問題在這裏：

首先，從2616音符旨在解決URI方案，其中不同類型的反應是由可在不同的URI的，如「/path/to/thing.xml」與「/path/to/thing.json」。這並不總是一個流行的選擇，但如果你能做到這一點，那就這樣做，並在每個「實體」中包含超鏈接。也就是在答覆的主體中。由於RFC沒有爲這些鏈接指定內容類型或處理模型，因此您應該如何返回它們，但帶有<a>標籤的HTML是常見且有用的。

如果您不想在單獨的URI處公開多個類型，但只想在原始URI處公開一個類型，那麼使用406和一個只說明資源可以發出哪些類型的實體。其次，請注意，大多數網頁瀏覽器在接受標頭中發送*/*（其質量較低），應該與任何內容類型相匹配。另外，規範說「如果不存在Accept頭字段，則假定客戶端接受所有媒體類型。」所以你應該提高406的情況很少見。

第三，不要發出除響應實體的內容類型以外的內容類型響應頭。應該使用而不是來列出可接受的類型。您還應該而不是發出一個名爲'Accept'的響應標題; 「接受」標題僅用於請求;請參閱http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

來源

2010-12-16 23:39:37 fumanchu

+1個人而言，我將使用text/plain作爲406的返回內容類型，幷包含一些文本，如'此服務僅提供應用程序/ json' – 2010-12-17 00:39:33

@fumachu我不希望類型爲在URI中，我想通過Accept和Content-Type頭部「正確地」完成它（儘管它可能有點OTT）。我也知道瀏覽器傾向於發送'*/*'在這種情況下會使用默認的輸出格式（在這種情況下是JSON）。 – 2010-12-18 15:53:42

@fumachu謝謝澄清，這個「實體」的東西是實際的迴應。我在閱讀文檔時一定錯過了它（或者沒有明確說明）。 – 2010-12-18 15:54:39

如何正確發送406狀態碼？

回答

相關問題