我对使用REST的HATEOAS原理来减少SPA应用程序中的业务逻辑感兴趣。在特定于React的上下文中，我想知道是否存在使这变得不切实际的挑战，如果不是，那么遵循什么好的策略？
使用HATEOAS从UI删除业务逻辑的概念示例：
Delegating valid bank account actions to the REST service
Delegating role-based access control to the REST service
我只找到一个建议React/Flux is not compatible with a HATEOAS strategy的链接，而在其他地方没有有意义的讨论。在React / Flux应用程序中真的不可行吗？这样的帖子没有得到足够的重视。有没有人喜欢或推荐使用一种成功的方法（使用或不使用Flux或Redux）？
有人给出了leveraging HATEOAS in the context of Angular的相当详细的示例。我正在为React寻找类似的东西。
我个人在超媒体链接中描绘了rel标签，该链接控制呈现哪些JSX组件（conditional JSX）。现实世界中的React应用程序天真吗？也许有条件渲染的React组件太粗糙了而无法以这种方式使用？
我假设超媒体链接是由HAL实现提供的，或者符合ATOM提要约定（RFC4287）。
最佳答案
100％HATEOAS与React＆Flux兼容，HATEOAS与Angular兼容，HATEOAS与JQuery甚至香草JS兼容。
HATEOAS并没有对使用客户施加任何技术或实施要求。
HATEOAS实际上只是可以设计API的一个概念（尽管可以使用几种标准之一，例如HAL）
基本上，如果可以调用API，则可以实现HATEOAS客户端。
那么如何到达那里：
第1步，您通常如何在React中进行API调用？用同样的方法做。
步骤2，询问响应。
步骤3基于响应，在UI中进行适当响应。
例如，给定订单api /orders的调用，我得到以下响应：
{
"_links": {
"self": { "href": "/orders" },
"next": { "href": "/orders?page=2" }
}
}
据此，我可以推断
next是有效的关系，并且如果我转到该href，我实际上会收到第二页的订单，因此在这种情况下，在UI中显示下一个按钮。但是，如果我收到以下答复：
{
"_links": {
"self": { "href": "/orders" },
}
}
然后，我可以推断
next不是有效的关系，并且在我的UI中应该禁用或不显示下一个按钮。没有魔术，只是思维上的改变，一种新的范例。