数据的语义是REST不可或缺的一部分吗? [英] Is the semantic of the data integral part of REST?
问题描述
这是对要求解释的问题的跟进REST .
从我对答案的评论中可以看出，我们与 Darrel Miller 有一个小的论点关于资源的最佳媒体表现形式.我们进行了进一步的电子邮件讨论，从而导致了这个问题.
Darrel和我对REST的理解之间的主要区别是数据的语义是否属于REST API的一部分.
Darrel相信(我对他的话的解释:-))，数据的语义是REST API的重要组成部分，因此，所选的媒体表示形式应反映出它.因此，适当的REST API应该选择以下任意一种:
- 像ATOM这样的著名媒体代表数据，以便许多客户端可以本地理解资源的语义；
- 特定于应用程序的媒体类型，例如application/vdn.mycomany.mymedia，希望客户端理解该媒体类型以能够使用资源数据. Application/xml不是很好的资源表示形式，因为它不能表示媒体类型中的语义，但需要客户端更多地了解语义.
因此，问题:REST API的数据语义部分吗?对于资源表示，我们是否应该只选择实际上代表数据语义的媒体类型?
如果人们在答案中张贴一些引文，最好是罗伊人本人的引文，我将不胜感激. :-)
让我们从头开始:媒体类型可以为客户端提供一种可用于决定下一步操作的格式.没有html页面，浏览器将没有链接.没有html渲染器，浏览器将无法渲染页面，并且不知道该怎么办.
没有媒体类型，客户端不知道是否可以对字节流执行任何操作.确实，当客户端收到指定application/xml的标头时，除了获得xml解析器之外，它不知道该做什么.
所以问题实际上是，客户端是否应该能够基于http消息做出决定而无需查看消息内部，还是应该去窥视消息内部(或更糟糕的是，首先解析消息)来知道该怎么办.
缺少媒体类型意味着您的客户在做出决定(用于呈现还是用于处理)之前，将不得不进行其他窥视工作，或者对实体本身进行更差的处理.现在，您必须为可能要处理的每种格式添加很多自定义行为，并且在处理过程中会失去一些耦合.
这也是http的基础知识，中介程序应该能够在不检查主体的情况下处理请求，并且application/xml也是有问题的.
现在，当您说媒体类型的语义是否属于API的一部分时... API的构成是什么?
从客户端的角度来看，没有API.有一个初始表示，使客户可以决定下一步要做什么.实际上，媒体类型是客户端获取导航"API"所需的信息的地方，因此，没有表示形式就不可能有API.
此外，客户端应该只具备三点知识:引导位置，HTTP协议和媒体类型.第一个只是URI，不会超出继续所需的重新设置位置.第二个已经具有非常清晰的语义.第三是您可以控制的合同，因为这是您与客户之间的合同.
这种矛盾表明，每当您想做某事时，这些事就会具有语义:添加客户，使用POST将application/vnd.acme.customer + xml发送到/customers.
因此，我的回答:设计REST体系结构取决于两个步骤:资源建模(在概念级别)和媒体类型构建.还有其他事情，您可能做错了.
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. :-)
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.
这篇关于数据的语义是REST不可或缺的一部分吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
