the*_*hai 3 rest hateoas restful-architecture
是否存在代表使用和利用 RESTful 原则实现的真实世界应用程序的概念验证客户端（即 Web 应用程序）？我能找到的只有 API 浏览器，但现实世界应用程序（即社交网络或电子商务网站）的开发却大不相同。
我已经阅读了 Roy 的作品和相关论文，但我仍然无法理解如何在客户端开发中充分利用 Restful。我总是最终在客户端上存储状态或专门进行媒体/类型渲染。例如，相同的资源（即配置文件资源）根据上下文（即在主页、产品页面或专用配置文件页面上）以不同的方式呈现，因此告别媒体类型-> 代码按需呈现。
我真的看不出 HATEOAS 比具有明确定义/自动生成的IDL（即 json 超模式）的 API 有任何优势（以我的工作方式）。
我目前的结论是只有通用客户端（即谷歌）可以从 HATEOS 中受益，而不是现实世界/专业应用程序。如果您的 API 启用了 HATEOS 而不是IDL描述，那么专门的客户端开发似乎没有任何好处。
虽然 HATEOAS 确实为您提供了 URI 灵活性和人工发现流，但真正的好处是将其用作资源状态的编码。
如果您有一个与资源关联的状态机，您将拥有一些允许某些状态转换而不是其他状态转换的状态。
通过对资源 URI 的操作，为 REST 客户端提供了实现可能的状态转换的机会 - 使用 HATEAOS 超媒体，您可以通过已知的 rel 链接名称定义转换，然后包含或排除 rel 链接，具体取决于允许哪些转换按目前的状态。
这意味着确定哪些转换有效的逻辑保留在服务器端 - 客户端可以根据关联的 rel 链接是否存在来选择隐藏或禁用 UI 选项。
包含或排除特定 rel 链接的另一个原因可能与提供给当前用户的访问控制权限有关。如果当前用户未被允许执行转换，只需将它们排除在外。
如果您没有根据资源状态和/或授权用户的状态动态地包含或排除 rel 链接，那么您对利弊的分析非常准确，因为您没有使用它们的真正原因是它们被包含在内。毕竟，REST 中的S代表状态！:)
| 归档时间： |
|
| 查看次数： |
867 次 |
| 最近记录： |