[英]How should a React app (or any SPA) interact with a HATEOAS back-end?
The basic question is if there should be one HATEOAS entry point per page or one entry point for the entire app?基本问题是每页应该有一个 HATEOAS 入口点还是整个应用程序有一个入口点?
Most examples I have seen implement a single page with a HATEOAS backend, eg a list that is paginated using prev
and next
links.我见过的大多数示例都实现了带有 HATEOAS 后端的单个页面,例如使用
prev
和next
链接分页的列表。 But what happens when the app navigates to a different page that has completely different capabilities and needs a different entry point?但是,当应用导航到具有完全不同功能且需要不同入口点的不同页面时会发生什么? How does one organize such an app?
如何组织这样一个应用程序?
Concrete example : We have an app with tab navigation.具体示例:我们有一个带有标签导航的应用程序。 The home tab shows a product catalog so the entry point is
/products
which returns page 1 of products along with pagination links.主页选项卡显示产品目录,因此入口点是
/products
,它返回/products
第 1 页以及分页链接。 However, now I click on the orders tab which must show a list of past orders.但是,现在我单击必须显示过去订单列表的订单选项卡。 This page needs a completely different entry point
/orders
which the home tab knows nothing about.此页面需要一个完全不同的入口点
/orders
,主页选项卡对此一无所知。 In fact, user can directly navigate to the orders tab using a deep link.事实上,用户可以使用深层链接直接导航到订单选项卡。
How to think about this problem?如何思考这个问题? Are there any examples illustrating an approach?
是否有任何示例说明了一种方法?
There's a few different ways to solve this.有几种不同的方法可以解决这个问题。 Here's two:
这里有两个:
We're going more towards #2.我们更倾向于#2。 If we have a uri such as:
如果我们有一个 uri,例如:
https://spa.example/https://api.example/foo/bar
We take the path part of this uri and hit the API.我们获取这个 uri 的路径部分并点击 API。 Based on what the API responds with, we decide what to render.
根据 API 的响应,我们决定渲染什么。 This means that most of the routing for these kinds of endpoints is delegated to the server, which feels more in line with HATEOAS.
这意味着这类端点的大部分路由都委托给了服务器,这感觉更符合 HATEOAS。
The path part in this case is an entire absolute URI, but we also support relative uris and have a default base uri.在这种情况下,路径部分是一个完整的绝对 URI,但我们也支持相对 uri 并有一个默认的基本 uri。 So in practice these two uris are equivalent (for our SPA):
所以在实践中这两个 uri 是等效的(对于我们的 SPA):
https://spa.example/https://api.example/foo/bar
https://spa.example/foo/bar
We develop & use ketting / react-ketting to do most of the heavy lifting我们开发和使用ketting / react-ketting来完成大部分繁重的工作
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.