java - HATEOAS 和 API 的动态发现

Question

HATEOAS 原则“客户端仅通过服务器在超媒体内动态识别的动作进行状态转换”

现在我对动态这个词有疑问，尽管我猜它是那里最重要的一个词。

如果我在 API 中将我的参数之一从说可选更改为强制，我必须修复我的客户端，否则请求将失败。

简而言之，HATEOAS 所做的只是给予服务器端开发人员极大的自由来随意更改 API，代价是所有客户端都使用他/她的 API。

我这样说是对的，还是我错过了诸如版本控制之类的东西，或者可能是服务器必须采用的 JSON 以外的其他媒体类型？

Answer 1

每当您将 API 中的参数从可选更改为强制时，都会破坏该 API 的使用者。它是一个遵循 HATEOAS 原则的 REST API 不会以任何方式改变这一点。相反，如果您希望保持兼容性，则应避免进行此类更改；确保客户端针对旧 API 编写的任何调用或发送的消息将继续按预期运行。

另一方面，最好不要让客户端期望返回的元素集总是相同的。如果服务器选择提供附加信息，他们应该能够忽略服务器提供的附加信息。同样，这只是很好的 API 设计。

HATEOAS 不是问题。过分严格的 API 期望是问题所在。HATEOAS 只是问题解决方案的一部分（因为它可能使客户不必了解大量关于服务的状态模型，即使它不一定使它直截了当）。

Answer 2

Donal Fellows 有一个很好的答案，但同一枚硬币还有另一面。HATEOAS 原则对消息的格式没有任何规定（REST 的其他部分有）；相反，它本质上意味着客户端不应该尝试知道在带外对哪个 URI 进行操作。相反，服务器应该通过超链接（或构建超链接的表单/模板）告诉客户端哪些 URI 是感兴趣的。这个怎么运作：

1. 客户端从状态 0 开始。
2. 客户端请求一个众所周知的资源。
3. 服务器的响应将客户端移动到新状态N。根据响应代码和有效负载，此时可能有多种状态可实现。
4. 响应包括链接（或表单/模板），它们在 band中告诉客户端一组潜在的下一个状态。
5. 客户端通过在 URI 上发出方法来选择可能的下一个状态之一。

重复 3 到 5 到状态N+1及以后，直到满足客户端的应用程序需求。

以这种方式，服务器可以自由地更改将客户端从状态N移动到状态N+1的 URI，而不会破坏客户端。

Answer 3

在我看来，您误解了引用的原则。您的问题表明您考虑资源并且可以“动态”定义它们。就像在应用程序运行时添加到某些资源类型的强制属性一样。这不是原则所说的，这在其他答案中得到了正确指出。引用的原则说，超媒体内的动作应该是动态识别的。

可用于给定资源的操作可能会随时间改变（例如，因为同时有人添加/删除了关系），并且可能有不同的操作可用于相同的资源但针对不同的用户（例如，因为用户具有不同的授权级别）。HATEOAS 的想法是，客户不应该对在任何给定时间对某些资源可用的操作有任何假设。客户端应在每次读取该资源时识别可用的操作。

编辑：以下段落可能是错误的。请参阅评论以进行讨论。

另一方面，客户可能对资源中可用的数据有期望。就像一个book资源必须有一个title，并且它可能有指向该书作者的链接。没有办法避免这些假设引入的耦合，但服务提供者和客户都应该使用向后兼容和版本控制技术来处理它。