我正在開發一個REST API，我對資源表示有個疑問。不同的資源表示（REST API）
假設我在/ app/person/{id} URI下獲得了「人員」資源。我需要一個XML表示法，基本上所有對象字段都是根節點下的XML節點。現在需求表明我們還必須支持另一種由專有架構強制執行的XML表示。
問題是：在REST最佳實踐下是否支持相同資源的專有內容類型（如「text/my-type」）？注意兩者都是XML格式，但格式不同，最重要的是它們沒有攜帶相同的信息（例如，一個表示可能包含其他字段，如「modified-since」）
重要！：我知道務實和保持它很簡單，它比指南和「最佳實踐」更重要，但我只是想知道這是在RESTful架構下走向何方。
是和否。沒有REST約束會阻止您從同一個URL返回資源的兩個不同表示。即使如果一種媒體類型是專有格式。請注意允許內容變化太大，我聽說有些人對此感到非常不安。 另外，對於自定義格式，您應該使用供應商子樹下的媒體類型
應用程序/ vnd.companyname.format + xml
然而，它不是真正的REST精神返回專有格式。話雖如此，除了限制偶然重複使用之外，你可以做任何問題。
REST對專有格式沒有任何問題 - HATEOS實際上完美地描述了這種情況。想要與RESTful服務交互的客戶端只需要知道該服務返回的媒體類型（不管它們是jpeg，Atom XML，Word文檔等） – Gandalf 2009-08-18 18:27:51
如果這些只是Person資源的兩種不同表示方式，那麼您應該爲它們設置兩種媒體類型。如果可能的話嘗試查找並重新使用標準表示及其媒體類型（請參閱http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven）。這兩種媒體類型應該有application/類型+xml（參見Darrel的評論）。
基於xml的自定義類型被命名爲application/type + xml。如果您正在創建自己的自定義類型，那麼通常會在供應商子樹下創建它們。例如application/vnd.mycompany.mytype + xml – 2009-08-18 12:31:05
感謝Darrel，我翻了翻了「xml」和「type」。 – 2009-08-18 15:00:39
謝謝吉姆，鏈接雖然破壞 – 2009-08-18 20:11:53
內容協商使用Accept和Accept-Encoding標頭構建到HTTP中。客戶端應用程序應該通過設置這些標題來指定他們想要返回的類型。
這並不回答我所問的內容......似乎評論不僅僅是答案 – 2009-08-18 20:11:10
他的評論意味着HTTP協議具有強大的內置功能來處理從同一資源返回多個表示。 – HDave 2012-03-19 16:02:15
如果第二種格式僅僅是一種不同的語法（或可以合理地被視爲這樣），那麼將它作爲另一種媒體類型的第二種表示方式添加它是完全正確的（並且符合REST最佳實踐）。如果你認爲差異不僅僅是語法，你應該創建一個不同的資源。如果你想能夠鏈接到一個特定的表示（如果你想這樣做，它需要一個不同的URI），情況也是如此。在後一種情況下，您可能需要考慮一個規範化的，與格式無關的資源，該資源可以返回303 See Other以指向特定的鏈接。
如果您在API中指定URI命名方案（如/ app/person/{id}），那麼您的API是RPC，而不是REST。 – aehlke 2009-08-18 14:05:57
@Wahnfrieden 您能否解釋爲什麼URI命名方案意味着RPC。恕我不能贊同。/app/person/{id}是對個人資源的引用。除了說明哪裏可以找到人員資源，這個URI什麼也不做，完全是RESTful。當你使用URI來調用一個動作時，一個RPC URI就像/ app/dancing/dothefunkychicken？personid = {id}。 – 2009-08-18 15:34:42
@pablo是@Wahnfrieden確實知道REST是什麼。問題在於很多人試圖通過定義一組端點來定義REST API，就像他們定義RPC API一樣。 REST API不能以這種方式工作。 REST API設計應該關注媒體類型的定義。端點與客戶端以及API的RESTfulness完全無關。但是，服務器實現並不關心URL，因此在設計時很難讓人們忽略它們。 – 2009-08-18 20:36:29