HATEOAS Rel - 任何标准呢？

Question

我刚刚开始为我正在构建的WebAPI编写客户端实现.API已经使用了HATEOAS,因此我正在相应地编写客户端.我正在使用RestSharp作为客户端的基础.

客户端在构建时传递api base url(" https:// myapi/start "),它会触发请求,然后传递一组uris用于其他可用资源 - 授权(" https:// myapi /授权 ")并请求访问令牌(" https:// myapi/tokens ")以授权其调用api上的安全资源.

问题是,是否已针对返回的超媒体中的rel =""要求制定了标准？

Answer 1

我相信超文本应用语言(HAL)是一个标准草案 - 试图在超媒体之间标准化这些链接.

这是JSON规范草案的链接http://tools.ietf.org/html/draft-kelly-json-hal-03

HAL规范强制"href"符合Web链接规范(RFC 5988)中定义的"目标IRI"

在这里使用C#有一个HAL的XML实现https://github.com/tavis-software

上面的相同GitHub存储库还包含RFC 5988的示例.Net实现.

Answer 2

该网站链接规范,RFC5988,如已经指出了另一个答案,定义了一些不同类型的链接关系的.但它还指示IANA创建链接关系注册表并允许进一步的链接关系注册.该注册表是公共链接关系的最终列表,可在iana.org/assignments/link-relations上获得,并将在注册新关系时进行更新.

HTTP API中常用的关系包括:

• start (从每个资源指向API起点)
• item (从集合指向项目,例如从Twitter用户页面到推文)
• collection(反向item)
• previous (接下来的四个用于分页资源,例如集合或多页文章)
• next
• first
• last
• create-form (从集合指向描述如何创建新集合项的资源,例如"新项"HTML或XForms表单)
• edit-form (从项目指向用于编辑该项目的表单,例如编辑推文按钮)

如果该列表中的任何内容未涵盖您所需的关系,则您的关系必须是URI.此外,建议在您控制的域中将该URI设置为可解除引用的http URL,以便API客户端可以查找关系的文档,例如http://www.example.com/link-relations#tweets.通常,您的API起点将是一个集合列表,每个集合都有一个自定义链接关系,用于描述每个集合包含的资源类型.

Answer 3

在进一步讨论 HATEOAS 标准之前，我想强调一下，在实现 HATEOAS（现在也称为超媒体 API）的 API 中有三个主要概念：

• HTTP 协议。在使用动词和返回代码时，您必须尊重其约束。您还应该了解标题的作用，尤其是Content-type，以及某些动词的幂等性等微妙之处。有关更多信息，请参阅 RFC 2616
• URI 结构。其中必须仅提供有关定位资源的信息，并避免上下文数据。已知的坏例子是例如在 URI 中包含语言/en/、版本/v01/、格式/json/甚至动词/do-something/。RFC 3986 和 REST 指南中的更多信息
• 上下文数据，可以在正文、请求参数或标头中找到

REST 库的开发人员在 URI 和 HTTP 方面有严格的指导方针，但缺乏关于上下文数据以及它如何与请求的 JSON 正文中的应用程序数据混合的通用标准。

这就是为什么围绕 HATEOAS 的标准化工作主要是制定关于media-type. 那里有几个

• JSON HAL (ca 2012)，正如 Mark Jones 所概述的那样是最著名的
• Collections + JSON (ca 2013)，没有得到太多关注
• Verbose (ca 2014) 试图统一所有其他努力，但只有专家知道
• Siren (ca 2017) 在 github 上有大约 1000 颗星
• JSON:API（大约 2015 年，但仍在进行中）是当前的参考，其 1.0 版有很多实现，并得到了 Steve Klabnik 的支持，他围绕该主题撰写了大量内容

关于你原来的问题，看到这里的JSON:API有关相关资源链接报表。

希望这能帮助任何在 2019 年有同样担忧的人。

Answer 4

该 IETF 提议的标准RFC5988 文档描述了不同类型的链路关系和提议的用法。它的重点是 HTTP 链接标头规范，但也包括对其他链接关系类型的讨论。与一些（大多数？）RFC 一样，阅读它可能会让您比开始时更加困惑，但从长远来看，它值得付出努力。它会回答您问题中双引号之间的内容吗？可能不会，但至少你会得到一些想法来指导你的选择。