问题标签 [hateoas]

HATEOAS 背后的核心理念之一是客户端应该能够从单个入口点 URL 开始，并发现所有可用的公开资源和状态转换。虽然我可以完美地看到它如何与 HTML 和浏览器后面的人点击链接和“提交”按钮一起工作，但我想知道如何将这一原则应用于我（不）幸运地处理的问题。

我喜欢 RESTful 设计原则在论文和教育文章中的呈现方式，这一切都很有意义，How to GET a Cup of Coffee就是一个很好的例子。我将尝试遵循惯例并提出一个简单且没有繁琐细节的示例。让我们看看邮政编码和城市。

问题 1

假设我想设计用于通过邮政编码查找城市的 RESTful api。我想出了嵌套在邮政编码中的称为“城市”的资源，因此 GET onhttp://api.addressbook.com/zip_codes/02125/cities返回包含例如代表多切斯特和波士顿的两条记录的文档。

我的问题是：如何通过 HATEOAS 发现这样的 url？公开所有 ~40K 邮政编码的索引可能不切实际http://api.addressbook.com/zip_codes。即使拥有 40K 项目索引不是问题，请记住我已经制作了这个示例，并且那里有更大数量的集合。

所以本质上，我想公开的不是链接，而是链接模板，而是像这样：http://api.addressbook.com/zip_codes/{:zip_code}/cities，这违背了原则，并且依赖于客户拥有的带外知识。

问题 2

假设我想公开具有某些过滤功能的城市索引：

• GET onhttp://api.addressbook.com/cities?name=X将仅返回名称匹配的城市X。

• GET onhttp://api.addressbook.com/cities?min_population=Y只会返回人口等于或大于Y.

当然这两个过滤器可以一起使用：http://api.addressbook.com/cities?name=X&min_population=Y.

在这里，我不仅要公开 url，还要公开这两个可能的查询选项以及它们可以组合的事实。如果没有客户对这些过滤器的语义和将它们组合成动态 URL 背后的原则的带外知识，这似乎是根本不可能的。

那么 HATEOAS 背后的原则是如何帮助使这些微不足道的 API 真正成为 RESTful 的呢？

我试图对 HATEOAS 有一个清晰简洁的理解，我绝不是 WRT REST 专家。（我想我明白了，多亏了这个http://www.looah.com/source/view/2284）。

任何人都可以推荐一个同样具有启发性的博客/文章 WRT HATEOAS 吗？

对于我参与的一家 SaaS 初创公司，我正在构建一个 RESTful Web API 和几个使用它的不同平台上的客户端应用程序。我想我已经弄清楚了 API，但现在我正在求助于客户。正如我一直在阅读有关 REST 的内容，我发现 REST 的一个关键部分是发现，但是对于发现的真正含义的两种不同解释之间似乎存在很多争论：

1. 开发人员发现：开发人员将大量 API 详细信息硬编码到客户端中，例如资源 URI、查询参数、支持的 HTTP 方法以及他们通过浏览文档和试验 API 响应发现的其他详细信息。恕我直言，这种类型的发现需要很酷的链接和 API 版本控制问题，并导致客户端代码与 API 的硬耦合。看起来并不比使用有据可查的 RPC 集合好多少。

2. 运行时发现- 客户端应用程序本身能够找出它需要的一切，几乎没有或没有带外信息（大概，只有 API 处理的媒体类型的知识。）链接可能很热。但是为了使 API 非常高效，似乎需要对查询参数进行大量链接模板，这使得带外信息重新出现。可能还有其他我还没有想到的困难，因为我还没有想到发展到了那个地步。但我确实喜欢松散耦合的想法。

运行时发现似乎是 REST 的圣杯，但我看到很少有人讨论如何实现这样的客户端。我发现的几乎所有 REST 源似乎都假设开发人员发现。有人知道一些运行时发现资源吗？最佳实践？带有真实代码的示例或库？我正在为一个客户端使用 PHP（Zend 框架）。另一个是 Objective-C (iOS)。

考虑到开发人员社区目前的工具和知识，运行时发现是一个现实的目标吗？我可以编写我的客户端以不透明的方式处理所有 URI，但是如何最有效地做到这一点是一个问题，尤其是在低带宽连接上。无论如何，URI 只是等式的一部分。运行时上下文中的链接模板怎么样？除了发出很多 OPTIONS 请求之外，如何交流支持哪些方法？

使用 REST API 工作，遇到了一个问题，我想传递一个表示关系的值，但也传递该关系的 URL，以便它可以符合 HATEOAS。

我想我已经提出了一个合适的解决方案，但希望得到那些比我更有知识的人的确认。

这个 RESTful JSON 响应是否仍然符合 HATEOAS 原则？

那么大家怎么看呢？这种格式会起作用吗？

根据下面@fumanchu 的建议，这是我现在尝试使用的格式...

谢谢指导！

我在这里阅读了很多关于 SO 的讨论，观看了Jon Moore 的演示文稿（顺便说一句，其中解释了很多）并阅读了 Roy Fielding 在 HATEOAS 上的博客文章，但在客户端设计方面我仍然感到有点茫然。

API 问题

现在，我只是返回带有表单/锚点和定义列表的 xhtml 来表示资源。以下片段详细说明了我如何布置表单/锚点/列表。

我的问题主要是针对表格的。在 Jon 的演讲中，他记录了诸如 (add_location_form) 等表单类型以及它们所需的输入。我没有很多资源，但我正在考虑抽象表单类型（添加、删除、更新等），并且只是在文档中注意（添加、更新）您必须发送目标资源的有效表示并删除，您必须发送标识符。

问题 1：使用 HATEOAS 的概念，我们真的不应该让客户端“发现”表单（通过对它们进行分类添加、删除、更新等）并发送回我们提供给它们的所有数据吗？我在这里的真正问题（不是要讨论）是这是否遵循良好的做法？

客户问题

在 HATEOAS 之后，我们对资源的操作是可发现的，这将如何影响客户端代码（api 的消费者）及其 ui。遵循这些原则，UI 应该只显示可用的操作，这听起来很棒，但它是如何实现的？

我目前的方法是将响应解析为 xml 并使用 xpath 来查找在客户端开发时已知的操作（记录的表单类，即添加、删除、更新）并显示 ui 控件（如果它们可用）。

问题2：我的发现方式错了吗？还是就客户而言，这太神奇了（知道表单类）？这不是假设客户端知道每个资源可以使用哪些操作（这可能很好，因为它是创建客户端的某种原因，对吗？）并且应该记录操作（表单类）到资源的映射，或者只是记录表单类并允许客户（和客户开发人员）研究和发现它们？

我知道我无处不在，但任何洞察力都非常感谢。我将标记为很好地回答了这两个问题中的任何一个的回复。谢谢！

我正在为 RESTful API 设计自定义媒体类型，并研究了一些“标准”链接关系的类型和语义含义，以便为我的设计提供一些指导。

为了演示这个问题，假设我有一个可以执行标准读取、更改、删​​除方法的资源，并且我分别使用 GET、PUT 和 DELETE 的 HTTP 习惯用法来实现这些方法。

我可以合理地（重新）使用RFC5023中定义的“编辑”链接关系（来自IANA 链接注册表），其中规定：

"..."edit" 的值指定 href 属性的值是可编辑成员条目的 IRI。当出现在 atom:entry 中时，href IRI 可用于检索、更新和删除资源由那个条目代表......”

这样，用户代理可以理解具有“编辑”关系的链接将允许对资源进行 GET、PUT 和 DELETE。

然而，问题就在这里，如果资源状态被编辑使得资源现在只支持 GET 和 DELETE 操作，“编辑”关系就不再精确。

为了保持精度，我需要 i) 选项 A：指定另一个（复合）链接关系，仅支持 GET & DELETE，或 ii) 选项 B：为每个可能的状态转移指定单独的链接并使用适当的链接来指示允许的状态转移。后一种方法提供了精确性，但似乎过于冗长。

或者，（选项 C）我可以保留“编辑”关系并接受缺乏精度，即链接将传达 GET、PUT、DELETE 语义，但尝试 PUT 的用户代理将遇到 HTTP 错误' 405 - 不允许的方法'。但是，我对这种方法也不满意，因为它向客户端暗示了不支持的状态转换。

总而言之，问题是平衡链接关系通用性和精度的最明智的方法是什么？

我已经开始尝试使用 Backbone.js，并且对 Backbone.Model 上的url属性的文档感到震惊。

特别是，我正在构建一个 REST API，它使用 HATEOAS/超媒体来驱动客户端。

我可以看到 Backbone 为集合中的项目构建 URL 本身的默认行为的有用性，但就我而言，我更愿意使用已解析的数据构建模型 URL。

有没有人在 Backbone 上扩展/构建来做到这一点？也许建立在像HAL这样的“标准”之上？

编辑：

为了澄清，假设我有以下内容：

获取/订单>>

我有一个 Order 模型，例如：

我希望该url属性自动从 HAL 中的“自我”引用中提取出来。我认为创建一个新的基本模型类似于（未测试）：

想法？

就菲尔丁的论文（内容协商、超媒体等）而言，是否有任何真正 100% RESTful 的现实生活中的 Web 服务。我想更好地掌握 REST，并且需要我可以从像 Restfulie 这样的自动化客户端使用的东西。到目前为止，我遇到的所有声称是 RESTful 的东西实际上似乎都是 RPC 或 HTTP CRUD。

在创建自己的自定义媒体类型格式（例如 application/vnd.myapp+xml）时，客户端在发送正文内容时是否应该在自定义媒体类型中这样做？

例如，您将订单的表示放入 uri。内容应该是 application/vnd.myapp+xml，还是只是 xml，因为客户端不会包含链接等超媒体控件？

如果用户接受它（它应该），服务器将始终使用自定义媒体类型进行响应，但是客户端是否必须在其请求正文中使用它？