REST 客户端实现拥抱 HATEOAS 约束? [英] REST Client Implementation Embracing HATEOAS Constraint?

问题描述

有谁知道包含 超媒体作为应用程序状态的引擎 (HATEOAS)?

Does anybody know of an implementation of a REST client that embraces the constraint of Hypermedia as the Engine of Application State (HATEOAS)?

Sun Cloud API 似乎是一个不错的选择，从它的方式来看记录和作者的声明大意是 Ruby、Java 和 Python 实现是在作品中.但到目前为止我没有发现代码的痕迹.

The Sun Cloud API seems to be a good candidate, judging from the way it's documented and a statement by the author to the effect that Ruby, Java, and Python implementations were in the works. But so far I've found no trace of the code.

我正在寻找任何东西 - 即使是部分实现也会有帮助.

I'm looking for anything - even a partial implementation would be helpful.

推荐答案

您应该首先查看的是通用 Web 浏览器.这是接受 HATEOAS 的客户的标准(至少在某种程度上).

The very first thing you should look at is the common web browser. It is the standard for a client that embraces HATEOAS (at least to some degree).

这就是超媒体的工作原理.简单到几乎让人痛苦:

This is how Hypermedia works. It's so simple that it's almost painful:

1. 您将浏览器指向 http://pigs-are-cool.org/
2. 浏览器加载 HTML 页面、图像、CSS 等.
   • 此时，应用程序(您的浏览体验)位于特定的 URI.
   • 浏览器正在显示该 URI 的内容

• 此时，应用程序位于不同的 URI
• 浏览器正在显示新 URI 的内容

现在简要说明这两个术语与网络浏览体验的关系:

Now for a short explanation of how the two terms relate to the web browsing experience:

• 超媒体 = 带有嵌入链接的 HTML 页面
• 应用程序状态 = 您在任何时间点在浏览器中看到的内容.

所以 HATEOAS 实际上描述了当你从一个网页转到另一个网页时，网页浏览器中发生的事情:

So HATEOAS actually describes what happens in a web browser when you go from web page to web page:

带有嵌入链接的 HTML 页面推动您在任何时间点在浏览器中看到的内容

HTML pages with embedded links drive what you see in the browser at any point in time

术语 HATEOAS 只是这种浏览体验的抽象.

The term HATEOAS is just an abstraction of this browsing experience.

RESTful 客户端应用程序的其他示例包括:

Other examples of RESTful client applications include:

• RSS 和 Feed 阅读器.他们遍历用户给他们的链接
• 大多数 AtomPub 博客客户.他们只需要一个服务文档的 URI，然后他们就可以从那里找到上传图片和博客文章、搜索等的位置.
• 可能是 Google 小工具(和类似工具)，但它们只是外观不同的浏览器.
• 网络爬虫也是 RESTful 客户端，但它们是一个利基市场.

RESTful 客户端软件的一些特点:

Some characteristics of RESTful client software:

• 客户端可以与任何服务器一起工作，前提是它使用了一些 URI 并且服务器以预期的结果进行响应(例如，对于一个 atom 博客客户端，一个 Atom 服务文档).
• 客户端除了可以在运行时发现的内容外，对服务器如何设计其 URI 一无所知
• 客户端了解足够多的媒体类型和链接关系以了解服务器在说什么(例如 Atom 或 RSS)
• 客户端使用嵌入的链接来查找其他资源；有些是自动的(比如 <img src=)，有些是手动的(比如 <a href=).

• The client works with with any server, given that it is primed with some URI and the server responds with an expected result (e.g. for an atom blog client, an Atom services document).
• The client knows nothing about how the server designs its URIs other than what it can find out at runtime
• The client knows enough media types and link relations to understand what the server is saying (e.g. Atom or RSS)
• The client uses embedded links to find other resources; some automatically (like <img src=) some manually (like <a href=).

它们通常由用户驱动，可以正确地称为用户代理"，除了 GoogleBot.

Very often they are driven by a user, and can correctly be termed "user agents", except for, say GoogleBot.

这篇关于REST 客户端实现拥抱 HATEOAS 约束?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！