REST客户端实现是否拥抱HATEOAS约束？

Question

有没有人知道REST客户端的实现是否包含Hypermedia作为应用程序状态引擎(HATEOAS)的约束？

在Sun云API似乎是一个不错的选择,从它的记录的方式,判断由作者声明该红宝石,Java和Python的实现是在作品中的效果.但到目前为止,我还没有发现代码的痕迹.

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

Answer 1

您应该首先看到的是常见的Web浏览器.它是包含HATEOAS(至少在某种程度上)的客户的标准.

这就是Hypermedia的工作原理.这很简单,几乎是痛苦的:

1. 你指向你的浏览器 http://pigs-are-cool.org/
2. 浏览器加载HTML页面,图像,CSS等.
   • 此时,应用程序(您的浏览体验)位于特定的URI.
   • 浏览器显示该URI的内容
3. 你在应用程序中看到一个链接
4. 你点击链接
5. 浏览器跟随链接
   • 此时,应用程序位于不同的URI
   • 浏览器显示新URI的内容

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

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

因此,HATEOAS实际上描述了当您从网页转到网页时Web浏览器中发生的情况:

带有嵌入式链接的HTML页面可以随时驱动您在浏览器中看到的内容

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

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

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

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

• 客户端与任何服务器一起工作,因为它使用一些URI进行准备,服务器响应预期结果(例如,对于原子博客客户端,Atom服务文档).
• 客户端对服务器如何设计其URI以及在运行时可以找到的内容一无所知
• 客户端知道足够的媒体类型和链接关系,以了解服务器所说的内容(例如Atom或RSS)
• 客户端使用嵌入式链接查找其他资源; 一些自动(如<img src=)手动(如<a href=).

它们通常由用户驱动,并且可以正确地称为"用户代理",GoogleBot除外.

Answer 2

Restfulie是一个Ruby,Java和C#框架,旨在支持构建使用HATEOAS的客户端和服务器.我没有用它,但看起来确实很有趣.

这是他们的java项目中的一些示例代码:

Order order = new Order();

// place the order
order = service("http://www.caelum.com.br/order").post(order);

// cancels it
resource(order).getTransition("cancel").execute();

再说一次,我不确定它到底是做什么的,或者它在实践中的效果如何,但它看起来确实很有趣.

Answer 3

HATEOAS 设计原则（REST 也是一组设计原则）意味着每个资源最多应该有一个固定的 URL。

其他所有相关内容都应该可以通过“超媒体”链接从该 URL 动态发现。

我刚刚在这里开始了一个维基百科存根