我正在开发一个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