这是对要求explanation of REST的问题的跟进。
从评论到我的回答可以看出，我们在资源的最佳媒体表示方面与Darrel Miller有一个小小的争论。我们进行了进一步的电子邮件讨论，结果就出现了这个问题。
Darrel和我对REST的理解之间的主要区别在于数据的语义是否是REST API的一部分。
达雷尔相信（我对他的话的解释:-)）数据的语义是REST API的重要组成部分，因此，选择的媒体表示应该反映它。因此，正确的REST API应该选择：因此，问题：是REST API的数据语义部分吗？我们是否应该只选择实际代表数据语义的资源表示的媒体类型？
如果人们在他们的答案中发布一些引用，我会很乐意，最好是来自罗伊本人。 ： - ）
答案 0 :(得分：4)
让我们从头开始：媒体类型用于为客户提供可用于决定下一步做什么的格式。没有html页面，浏览器没有链接去。如果没有html渲染器，浏览器将无法渲染页面，也无法知道该怎么做。
如果没有媒体类型，客户端就不知道它是否能够对字节流做任何事情。实际上，当客户端收到指定application / xml的头文件时，除了获取xml解析器之外，它不知道该做什么。
所以问题实际上是，如果客户端能够根据http消息做出决定而不查看消息内部，或者是否应该查看消息（或者更糟糕的是，首先解析消息）知道该怎么做。
缺少媒体类型意味着您的客户必须先做额外的窥视工作，或者更糟糕地处理实体主体本身，然后才能做出决定，无论是渲染还是处理。您现在必须为您可能要处理的每种格式添加许多自定义行为，并且在此过程中您会失去一些耦合。
这也是一个http基础，中介应该能够在不检查正文的情况下处理请求，而且application / xml也存在问题。
现在当你说媒体类型的语义是API的一部分或不是...... API的构成是什么？
从客户端的角度来看，没有API。有一个初始表示，让客户决定下一步该做什么。媒体类型确实是客户端获取导航“API”所需信息的地方，因此没有表示没有API。
此外，客户端应该只有三位知识：引导位置，HTTP协议和媒体类型。第一个只是一个URI，并没有超出继续所需的表示位置。第二个已经非常清晰的语义。第三个是您可以控制的，因为这是您与客户签订的合同。
这种矛盾说，每当你想要做某事时，这些东西都会有语义：添加一个客户，使用POST将一个application / vnd.acme.customer + xml发送给/ customers。
因此我的回答是：设计REST架构依赖于两个步骤：资源建模（在概念层面）和媒体类型构建。还有别的，你可能做错了。
答案 1 :(得分：0)
我认为不需要过于迂腐。资源可以暴露多个表示;每个都有自己的语义（甚至是语义的多个维度）。如果一个表示不提供特定用例所需的语义，则公开一个表示。
因此，一个没有的客户 了解数据，仍然可以消费 REST API。
我不确定这是一个很好的试金石测试是什么或不能成为一个体面的代表。客户可以使用文档但是不能很好地理解文档来做任何事情有什么用呢？我想我不明白“资源的基本处理”如何使application / xml比1s和0s的任意blob更好？
由于您要求提供引用，here's an article from Roy Fielding where he "proposes" a bitmap representation of social network graphs。我当然可以得到一台机器来显示这些位图，但是如果我不理解底层的社交网络图有什么用呢？将表示更改为application / xml是否允许天真的客户端从中提取未包含在位图中的其他含义？不。
答案 2 :(得分：0)