HATEOAS原则"客户端仅通过服务器在超媒体中动态识别的操作进行状态转换"
现在我对动态这个词有一个问题，尽管我想它是其中最重要的一个词。
如果我在API中将其中一个参数从say可选更改为强制，则我HAVE修复我的客户端，否则请求将失败。
简言之，HAEOAS所做的就是让服务器端开发人员有极大的自由来随意更改API，而所有客户端都要使用他/她的API。
我这样说是对的，还是我错过了版本控制之类的东西，或者可能是服务器必须采用的JSON之外的其他媒体类型？
在API中将参数从可选更改为强制时，将破坏该API的消费者。它是一个遵循HAEOAS原则的REST API，这无论如何都不会改变这一点。相反，如果您希望保持兼容性，则应避免进行此类更改；确保客户端根据旧API编写的任何调用或发送的消息将继续按预期运行。
另一方面，最好不要在编写客户端时期望返回的元素集总是相同的。如果服务器选择提供附加信息，他们应该能够忽略服务器提供的附加信息。同样，这只是一个好的API设计。
HAEOAS不是问题所在。API过高的期望是问题所在。HAEOAS只是问题解决方案的部分（因为它可能使客户端不必了解大量关于服务状态模型的信息，即使它不一定能直接实现）。
- 客户端在状态0启动
- 客户端请求一个已知的资源
- 服务器的响应将客户端移动到一个新状态N。根据响应代码和有效载荷，此时可能有多个状态可实现
- 响应包括链接（或表单/模板），这些链接告诉客户端，在频带中，潜在的下一个状态集
- 客户端通过在URI上发出一个方法来选择潜在的下一个状态之一
对N+1及以上状态重复3到5，直到满足客户端的应用程序需求。
以这种方式，服务器可以自由更改将客户端从状态N移动到状态N+1的URI，而不会破坏客户端。
在我看来，你误解了引用的原则。你的问题表明你考虑了资源，它们可以"动态"定义。就像在应用程序运行时添加到某个资源类型的强制属性一样。这是而不是原则所说的，其他答案也正确地指出了这一点。引用的原则说，超媒体中的动作应该被动态识别。
对于给定资源可用的动作可能会随着时间的推移而改变（例如，因为有人在此期间添加/删除了关系），并且对于相同的资源但对于不同的用户可能存在不同的可用动作（例如，由于用户具有不同的授权级别）。HATEOAS的思想是，客户端不应该对在任何给定时间可用于特定资源的操作有任何假设客户端每次读取该资源时都应确定可用的操作。
编辑：下面的一段可能是错的。有关它的讨论，请参阅评论。
另一方面，客户端可能对资源中可用的数据有期望。类似于book资源必须有title，并且它可能是指向该书作者的链接。无法避免这些假设引入的耦合，但服务提供商和客户端都应该使用向后兼容性和版本控制技术来处理它