REST (HATEOAS) 和 ReactJS

Question

我有兴趣使用 HATEOAS REST 原则减少 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 应用程序中真的不可行吗？那篇 SO 帖子没有得到足够的关注。有没有人有最喜欢或推荐的成功方法(使用或不使用 Flux 或 Redux)？

有人给出了一个相当详细的例子 leveraging HATEOAS in the context of Angular 。我正在寻找类似的 React 东西。

就我个人而言，我想象超媒体链接中的 rel 标记控制渲染哪些 JSX 组件 ( conditional JSX )。这对于现实世界的 React 应用来说是不是太天真了？也许条件渲染的 React 组件太粗粒度，无法以这种方式使用？

我假设超媒体链接是由 HAL 提供的实现，或以其他方式符合 ATOM feed 约定 ( RFC4287 )。

Answer 1

100% HATEOAS 与 React 和 Flux 兼容，HATEOAS 与 Angular 兼容，HATEOAS 与 JQuery 甚至 vanilla JS 兼容。

HATEOAS 不会对消费客户端强加任何技术或实现要求。

HATEOAS 实际上只是一个您可以设计 API 的概念(您可以使用多个标准之一，例如 HAL)

基本上，如果您可以调用 API，那么您就可以实现 HATEOAS 客户端。

如何到达那里:

• 第 1 步，您通常如何在 React 中进行 API 调用？用同样的方法做。
• 第 2 步，询问响应。
• 第 3 步，根据响应，在用户界面中做出适当响应。

例如，调用订单 api /orders，我得到以下响应:

{
    "_links": {
        "self": { "href": "/orders" },
        "next": { "href": "/orders?page=2" }
    }
}

据此我可以推断 next 是一个有效的关系，如果我转到该 href，我实际上会收到第二页订单，因此在这种情况下，在 UI 中显示下一步按钮。

但是，如果我收到以下回复:

{
    "_links": {
        "self": { "href": "/orders" },
    }
}

然后我可以推断 next 不是有效的关系，并且在我的 UI 中我应该禁用或不显示下一个按钮。

没有什么魔法，这只是思维的改变，一种新的范式。