rest - 在 REST 架构中，客户端如何使用超媒体？

Question

在学习 REST 架构时，我注意到超媒体似乎是统一接口(interface)约束成为 RESTful 的重要组成部分；但是，我很难根据在网络上找到的超媒体的定义来理解客户端如何使用这种超媒体概念。

根据我对 REST 的了解，超媒体基本上是在包含资源表示的休息响应中提供给客户端的链接(因此客户端只需要知道 REST 服务的基本入口点 url) .这些链接本质上是为了帮助客户端了解它对收到的表示有哪些选项(例如，如果我请求/children/资源，我可能会收到一个包含指向/children/youngest 的链接的子项的 xml 列表，/children/oldest/、children/create 等……这正是我很难理解的……为什么服务器必须将这些“超媒体”链接返回给客户端？客户端不应该已经知道这些链接吗？客户端不会自己阅读链接并正确遵循它们...有人必须事先编写客户端代码(例如 html 和/或 javascript)。这些链接对客户，如果客户应该已经知道他们？我错过了什么？

Answer 1

超媒体确实是创建 RESTful 接口(interface)的重要组成部分。但是，我认为完整的超媒体客户端 (sometimes referred to as HATEOAS) 只是变得更加 RESTful 的一个点。 Richardson Maturity Model描述了变得更加 RESTful 的 3 个步骤，在考虑在特定项目中采用多少 RESTful 模式时，我发现这些是很好的指导方针。

IMO，完整的超媒体客户端的最佳示例是 Web 浏览器。网络浏览器理解 html <a href>标签代表一个链接。链接的关键是用户可以在他们的旅程中发现功能。因此，在设计 RESTful API 时，可以应用相同的原则。

Why does the server have to return these "hypermedia" links to the client?

因此，一个原因是客户端(如果编写为公开链接)可以允许状态转换是可发现的。

使用链接的另一个好处是您的 API 将负责每个链接的结构和数据。因此，服务器端 API 正在为每个请求生成链接。这意味着服务器 API 可以在不中断客户端的情况下对链接进行更改(版本或结构)。

您可以构建一个没有链接的 RESTful API(Richardson 级别 2)，但是如果您想更改您的 API 请求之一的 URL，该怎么办？您需要实现版本控制策略(通过 url 或 header )，或者您需要为新功能创建一个新 url。随着时间的推移，这可能会失控。