REST Content-Type：它是基於擴展還是Accept頭？

Question

由REST風格的Web服務返回的表示（html，xml，json）應由url還是由Accept HTTP頭確定？

Answer 1

兩者都有效。從xml.com引用：

資源可能有多個 表示形式。有四種 常用交付 正確的資源表示，以 消費者的方式：

1. 服務器驅動的協商。服務提供者根據其客戶端的先前知識 來表示正確的 表示，或者使用在諸如接受， 接受字符集，接受編碼， 接受語言和用戶代理的HTTP報頭中提供的信息 。這種方法的缺點是 服務器可能沒有關於客戶真正想要什麼的最佳知識 。
2. 客戶端驅動的協商。客戶端向 服務器發起請求。服務器返回可用於表示的 列表。 客戶端然後選擇它想要的表示 ，並向服務器發送第二個請求到 。缺點是一個 客戶端需要發送兩個請求。
3. 代理驅動的協商。客戶端通過代理向服務器 發起請求。代理將 請求傳遞給服務器，並獲得 表示列表。代理 根據 選擇一個表示設置客戶端設置， 將表示返回到 客戶端。
4. URI指定的表示。客戶指定它在 想要在URI查詢字符串中的表示。

Answer 2

由於很多基於REST的網址沒有擴展名，你應該/必須立足於內容類型

編輯：我不是說這聽起來確實苛刻，更多的您將不得不注意內容類型，並且不總是能夠引用分機

Answer 3

如果提供，使用Accept標頭，URI作爲故障轉移。

Answer 4

這是一個沒有問題的問題。

接受依賴於conneg（內容協商）。 Conneg會讓客戶通過Accept：標題決定他們接受什麼媒體類型。然後，響應將採用該格式，並附帶Vary：Accept標頭。

另一方面，將資源公開爲/resource.json和/resource.xml也是可能的也是完全有效的。

理想的是實現兩個： /資源（支持連接的通用uri） /resource.xml /資源。json

/resources返回的conneg'd版本可以根據協商的媒體類型簡單地重定向到正確的uri。或者，可以從通用uri中返回正確的表示形式，並使用Content-Location來指定返回的特定表示形式。

Answer 5

由於您提到的是RESTful Web服務而不是任何Web服務，我會強烈推薦底層標準支持的內容 - HTTP 1.1及其依賴於Accept HTTP標頭的內容協商。

正如我在Can I change the headers of the HTTP request send by the browser的回答中所解釋的，地址（URI）和表示是RESTful設計的兩個截然不同的支柱，它們不需要混合。 當存在Accept標頭時，不應該濫用URI來嵌入可接受的表示。

只有當您的Web應用程序有可能在中間節點涉及的HTTP頭過濾的環境中運行並使用時，您應該支持基於URI的內容協商。真相被告知，如果任何可能和可行的話，這種侵入性或不正確的功能代理應該被替換。

乾杯！
Shonzilla

Answer 6

有使用內容類型的問題...我討論這在我的博客http://shouldersofgiants.co.uk/Blog終於在包括在URI表示在REST Web服務建議的理查森和Ruby

Answer 7

見Chapter 5 - Representational State Transfer (REST)入駐，節5.2.1.2 表徵的羅伊菲爾丁的dissertation上建築風格：

的表示的數據格式被稱爲媒體類型[48]。

看看鏈接，我們看到它指的是MIME。因此，我假定用HTTP的說法是用POST/PUT的Content-Type標題和GET的標題Accept來表示。

這裏是第（用於完整性）的其餘部分：

的表示可以根據消息的控制數據和的性質 被包括在消息中並且由 收件人處理媒體類型。某些媒體類型旨在用於自動處理，其中一些媒體類型旨在呈現供用戶查看， 以及一些媒體類型都可以同時處理。複合媒體類型可用於在單個消息中包含多個表示。

P.S：我不知道爲什麼人們從來不看的地方，剩下的就是真正定義...