鸡蛋里挑骨头与REST：是否标准JSON REST API违反HATEOAS？ [英] Splitting hairs with REST: Does a standard JSON REST API violate HATEOAS?
问题描述
今天上午我在做一些REST阅读和我遇到了 HATEOAS原则（超媒体作为应用状态的引擎） 。
I was doing some reading on REST this morning and I came across the HATEOAS principle ("hypermedia as the engine of application state").
引述 REST维基百科页面：
客户端只能通过那些超媒体中动态确定的服务器（例如，通过超文本链接内）的行动使状态转换。除了简单的固定入口点的应用程序，客户不承担任何特定的行动将可超越那些重新presentations $ P从服务器接收到的pviously $描述的任何特定资源。
Clients make state transitions only through actions that are dynamically identified within hypermedia by the server (e.g. by hyperlinks within hypertext). Except for simple fixed entry points to the application, a client does not assume that any particular actions will be available for any particular resources beyond those described in representations previously received from the server.
...如果应用程序状态（因此该API）发动机没有被超文本驱动，那么它不能RESTful的并且不能是REST API。期。
...if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.
我读这为：客户端只能请求根据从服务器（超文本）的响应的主体提供操作状态变化
I read this as: The client may only request state changes based on the actions made available from the body of the response from the server (the hypertext).
在一个HTML的世界，这非常有意义。客户只能够请求基础上，通过超文本（HTML）。向他们提供的链接状态变化（新行动/页）
In an HTML world, this makes perfect sense. The client should only be able to request state changes (new actions/pages) based on the links made available to them through the hypertext (HTML).
在资源重新在其他方面psented $ P $ - 如JSON，XML，YAML等这不是那么明显。
When the resource is represented in other ways - such as JSON, XML, YAML etc. This is not so apparent.
让我们看一个例子休息JSON API：
Let's take an example "REST" JSON API:
我通过发送POST请求创建一个新资源（例如新评论）
I create a new resource (a new comment for example) by sending a POST request to
/comments.json？ ＃使用参数...
服务器响应：
# Headers
HTTP/1.1 201 Created
Location: http://example.com/comments/3
Content-Type: application/json; charset=utf-8
... Etc.
# Body
{"id":3,"name":"Bodacious","body":"An awesome comment","post_id":"1"}
我知道，我现在可以访问在URI此评论的标题返回： http://example.com/comments/ 3.json
当我访问 http://example.com/comments/3.json 我看到：
{"id":3,"name":"Bodacious","body":"An awesome comment","post_id":"1"}
假设的API文档告诉我，我可以通过发送一个DELETE请求到相同的URI删除此评论。这是相当普遍的之间休息的API。
Suppose the API's documentation tells me that I can delete this comment by sending a DELETE request to the same URI. This is fairly common amongst "REST" APIs.
来自服务器的响应 GET http://example.com/comments/3.json 不告诉我是能够通过删除任何评论发送DELETE请求。所有这表明我是资源。
The response from the server at GET http://example.com/comments/3.json doesn't tell me anything about being able to delete the comment by sending a DELETE request. All it shows me is the resource.
这我也可以删除具有相同URL的注释是一些客户端知道通过了带外信息（文件），而不是从服务器的响应发现并推动的。
That I can also DELETE a comment with the same URL is something the client knows through out-of-band information (the documentation) and is not discovered and driven by the response from the server.
下面，在客户端的是假设的DELETE行动（以及可能其它）可用于该资源并且此信息尚未从服务器pviously接收$ P $
Here, the client is assuming that the DELETE action (and possible others) are available for this resource and this information has not been previously received from the server.
我有没有误解HATEOAS还是我说得不是符合上述描述不，严格意义上，是一个REST API的API？
Have I misunderstood HATEOAS or am I right in saying than an API matching the above description would not, in the strict sense, be a REST API?
我知道100％坚持REST并不总是可能或最务实的路要走。我已经张贴了这个问题纯粹是为了满足关于REST背后的理论我自己的好奇心，而不是在现实世界中的最佳实践的建议。
I'm aware 100% adherence to REST is not always possible or the most pragmatic way to go. I've posted this question purely to satisfy my own curiosity about the theory behind REST, not for advice on real world best-practice.
推荐答案
JSON作为一个超媒体类型不定义应用程序流的标识符。 HTML有链接，形式标记，指导用户通过一个过程。
JSON as a hypermedia type doesn't define an identifier for application flow. HTML has link and form tag that that guide a user through a process.
如果您的应用程序只与有关PUT，POST，DELETE，GET上的资源，你的文档很容易解释。
If your application is only concerned with PUT, POST, DELETE, GET on a resource, your documentation could easily explain that.
但是，如果它是复杂的东西加反驳评论和反驳是一个不同的资源，那么注释就需要将引导消费者建立反驳超媒体类型。
However, if it were more complicated like adding a rebuttal to a comment and that rebuttal was a different resource then the comment you would need hypermedia type that would guide the consumer create the rebuttal.
您可以使用HTML / XHTML，创建自己的胆大包天+ JSON'或者使用别的东西。这里有各种不同的媒体类型
<一href=\"http://www.iana.org/assignments/media-types/index.html\">http://www.iana.org/assignments/media-types/index.html
You could use HTML/XHTML, Create your own 'bodacious+json' or use something else. Here are all the different media types http://www.iana.org/assignments/media-types/index.html
我使用的HAL，它有一个pretty活性基团。下面是它的链接。
I'm using HAL and it has a pretty active group. Here are links to it.
<一个href=\"http://www.iana.org/assignments/media-types/application/vnd.hal+json\">http://www.iana.org/assignments/media-types/application/vnd.hal+json
http://stateless.co/hal_specification.html
这本书建立超媒体API的使用HTML5和节点深入到超媒体和媒体类型。它展示了如何创建XML或JSON特定的或通用的介质类型。
The book "Building Hypermedia APIs with HTML5 and Node" goes deep into hypermedia and media types. It shows how to create a media type for a specific or general purpose in XML or JSON.
这篇关于鸡蛋里挑骨头与REST：是否标准JSON REST API违反HATEOAS？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
