数据语义是 REST 不可分割的一部分吗？
正如您从我的回答的评论中看到的，我们与 Darrel Miller 关于最佳答案有一个小争论资源的媒体表示。 我们进行了进一步的电子邮件讨论，导致了这个问题。
Darrel 和我对 REST 的理解之间的主要区别在于数据的语义是否是 REST API 的一部分。
Darrel 相信（我对他的话的解释:-)）数据的语义是 REST API 的重要组成部分，因此，选择的媒体表示应该反映它。 因此，一个合适的 REST API 应该选择：
- 使用像 ATOM 这样的知名媒体来表示数据，以便尽可能多的客户端能够本机理解资源的语义；
- 应用程序特定的媒体类型，例如 application/vdn.mycomany.mymedia，并期望客户端了解此媒体类型以便能够使用资源数据。 Application/xml 不是一个好的资源表示，因为它不表示媒体类型中的语义，但需要客户端了解更多语义。
另一方面，我相信 REST API 是独立于实际数据表示的层。 API暴露的媒体类型只是一个传输资源数据的容器。 数据的实际语义是单独处理的。 因此，不理解数据的客户端仍然可以使用 REST API。 Application/xml 是一种非常好的数据表示形式，因为它允许理解模式的客户端紧密耦合，但仍然允许不理解模式的客户端对资源进行一些基本处理。
因此，问题：数据语义是 REST API 的一部分吗？ 我们是否应该只选择实际代表数据语义的资源表示媒体类型？
如果人们在他们的答案中发表一些引文，最好来自罗伊人本人，我将不胜感激。 :-)
This is a follow up on a question asking for an explanation of REST.
As you can see from the comments to my answer, we've had a small argument with Darrel Miller on the best media representation of the resources. We've had a further email discussion that resulted in this question.
The main difference between Darrel's and mine understanding of REST is whether the semantic of the data is part of the REST API.
Darrel believes (my interpretation of his words :-)) that the semantic of the data is an essential part of the REST API and as such, the media representation choosen should reflect it. Thus, a proper REST API should choose either:
- a well-known media like ATOM to represent the data, so that as many clients could understand the semantic of the resource natively;
- an app-specific media type like application/vdn.mycomany.mymedia and expect the client to understand this media type to be able to consume the resources data.
Application/xml is not a good resource representation, as it does not represent the semantic in the media type, yet requires the client to know more about the semantic.
I, on the other hand, believe that the REST API is a separate layer from the actual data representation. The media type exposed by the API is just a container to transfer the resource data. The actual semantic of the data is treated separately. Thus, a client that does not understand the data, can still consume the REST API. Application/xml is a really good data representation, as it allows tight coupling for clients that understand the schema, yet still allows client that don't understand the schema to do some basic processing of the resources.
Thus, the question: is the data semantic part of the REST API? Should we choose only media types for resources representation that actually represent the semantic of the data as well?
I would appreaciate if people post in their answers some citations, preferably from the Roy man himself. :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
让我们从头开始：媒体类型为客户端提供一种格式，客户端可以用它来决定下一步做什么。 如果没有 html 页面，浏览器就没有可访问的链接。 如果没有 html 渲染器，浏览器就无法渲染页面并且不知道该怎么做。
如果没有媒体类型，客户端不知道是否能够对字节流执行任何操作。 事实上，当客户端收到指定 application/xml 的标头时，它不知道除了获取 xml 解析器之外还能做什么。
所以问题实际上是，客户端是否应该能够根据 http 消息做出决定，而无需查看消息内部，或者应该查看消息内部（或更糟糕的是，首先解析消息）以了解要做什么做。
缺乏媒体类型意味着您的客户端在做出决定（无论是渲染还是处理）之前必须执行额外的窥视工作，或者更糟糕的是处理实体主体本身。 现在，您必须为您可能想要处理的每种格式添加大量自定义行为，并且在此过程中会失去一些耦合。
这也是 http 的基础，中介应该能够在不检查正文的情况下处理请求，并且 application/xml 也存在问题。
现在，当您说媒体类型的语义是否属于 API 的一部分时……API 是由什么构成的？
从客户端的角度来看，没有API。 有一个初始表示可以让客户决定下一步该做什么。 媒体类型确实是客户端获取导航“API”所需信息的地方，因此，没有表示就不可能有 API。
此外，客户端应该只具有三部分知识：引导位置、HTTP 协议和媒体类型。 第一个只是一个 URI，除了继续所需的表示位置之外，没有传达太多内容。 第二个已经有非常清晰的语义。 第三个是您拥有控制权的，因为这是您与客户签订的合同。
该合同规定，每当您想做某事时，该某事都会具有语义：要添加客户，请使用 POST 将 application/vnd.acme.customer+xml 发送到 /customers。
因此，我的答案是：设计 REST 架构依赖于两个步骤：资源建模（概念层面）和媒体类型构建。 任何其他事情，你都可能做错了。
Let's start at the beginning: media types are there to provide the client with a format it can use to decide what to do next. Without an html page, the browser has no links to go to. Without an html renderer, the browser cannot render a page and won't know what to do.
Without a media type, the client has no clue if it will be able to do anything with the byte stream. Indeed, when a client receives the headers specifying application/xml, it has no knowledge of what to do beyond get an xml parser.
So the question really is, should the client be able to make a decision based on the http message without having a look inside the message, or should it go and peek inside the message (or worse, parse the message first) to know what to do.
Lack of media types means that your client will have to do additional peeking work, or worse process the entity body itself, before it can make a decision, be it for rendering or for processing. You now have to add a lot of custom behavior for each of your formats you may want to process, and you loose a bit of coupling in the process.
It's also an http fundamental that intermediaries should be able to process the requests without inspecting the body, and there as well application/xml is problematic.
Now when you say that the semantic of the media types is part or not of the API... What constitutes the API?
From a client perspective, there is no API. There is an initial representation that lets the client make a decision as to what to do next. The media type is indeed where the client gets the information it requires to navigate the "API", and as such there can be no API without representations.
Furthermore, a client should have only three bits of knowledge: a bootstrap location, the HTTP protocol and the media types. The first is only a URI and doesn't convey much beyond the location of a represetnation needed to continue. The second has already very clear semantics. The third is the one where you have control, as it's the contract you have with your client.
That contraact says that whenever you want to do something, the something will have semantics: to add a customer, send a application/vnd.acme.customer+xml to /customers using a POST.
Hence my answer: designing a REST architecture relies on two steps: resource modeling (at the conceptual level) and media type building. Anything else and you're likely doing it wrong.
我认为没有必要对此过于迂腐。 一个资源可以公开多个表示； 每个都有自己的语义（甚至是多个维度的语义）。 如果一种表示不能提供特定用例所需的语义，则公开一种可以提供的语义。
我不确定这是否是一个很好的试金石，可以检验哪些内容可以代表，哪些内容不能代表。 如果客户可以使用文档但对文档的理解不足以对其进行任何操作，那么这有什么好处呢？ 我想我不明白“资源的基本处理”如何使 application/xml 成为比任意 1 和 0 的 blob 更好的选择？
既然您要求参考文献，这是 Roy Fielding 的一篇文章，他在其中“提出”社交网络图的位图表示。 我当然可以让一台机器来显示这些位图，但如果我不理解底层的社交网络图，那有什么用呢？ 将表示更改为 application/xml 是否允许天真的客户端从中提取位图中未包含的附加含义？ 没有。
I don't see the need to be overly pedantic about it. A resource can expose multiple representations; each with its own semantics (and even multiple dimensions of semantics at that). If one representation doesn't provide the semantics required by a particular use case, expose one that does.
I'm not sure that's a good litmus test for what does or does not make a decent representation. What good is a client that can consume a document but not understand it well enough to do anything with it? I guess I don't understand how "basic processing of resources" makes application/xml a better choice than some arbitrary blob of 1s and 0s?
Since you asked for references, here's an article from Roy Fielding where he "proposes" a bitmap representation of social network graphs. I can certainly get a machine to display these bitmaps, but of what use is that if I don't understand the underlying social network graph? Would changing the representation to application/xml allow a naive client to extract additional meaning from it that isn't contained in the bitmap? Nope.
查看 Mark Baker 的这套幻灯片，了解更多说明至于为什么 application/xml 不满足“自描述”约束。 您还可以阅读他博客上的许多帖子，包括 this 他继续解释为什么 application/xml + 命名空间不等于媒体类型。
Check out this set of slides from Mark Baker for more explanation as to why application/xml does not satisfy the "self-describing" constraint. You can also read a number of posts on his blog including this one where he continues to explain why application/xml + namespace is not equivalent to media-types.