HATEOAS和API的动态发现

Question

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

现在我对动词这个词有问题，虽然我猜它是那里最重要的一个词。

如果我在API中将我的某个参数从“可选”更改为“强制”，我 HAVE 来修复我的客户端，则请求将失败。

简而言之，所有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. 响应包括链接（或表单/模板），它告诉客户端带内，潜在的下一个状态集。
5. 客户端通过在URI上发布方法来选择潜在的下一个状态之一。

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

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

Answer 3

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

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

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

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