如何为Flux/Redux前端构造REST响应？

Question

我有一个问题，就是如何构造一个响应，返回与其他对象相关的对象(一对多/多对一)，并告诉我我构建端点的方式是否错误，或者是否有更好的方法。

我的场景:我有一个基于Flux的JS应用程序，我在那里有这样的商店：-开会-用户

为了简单起见，假设enduser是会议管理器，希望看到所有会议的表/列表，每一行将显示会议描述和日期，以及与会者的姓名、电子邮件和电话。

因此，在页面加载时，我向路由/meetings发出请求，该路由返回如下所示的对象：

{
    meetings: [
        {id: 1, date: '2016-01-01', attendees: [1, 2, 3]},
        {id: 2, date: '2016-01-02', attendees: [2, 3, 4]},
    ],
    allUsersIntersectedByMeetings: [
        {1, name: 'a', phone: '1800-01111'},
        {2, name: 'b', phone: '1800-02222'},
        {3, name: 'c', phone: '1800-03333'},
        {4, name: 'd', phone: '1800-04444'},
    ]
}

如果您注意到，我已经将用户数据与会议数组分开，这是为了压缩结果并防止发送有关同一个用户的重复信息(在我的示例中，用户数据非常小，但在现实生活中，用户表上可能有许多列)。

我将会议和用户分离开来的原因是，我不想返回大量重复的数据，因为在现实生活中，我将在一个请求中至少进行100次会议，用户可以在不同的会议上重复多次。

因此，使用这种结构，我将把所有的客户放在我的前端流量存储‘用户’，我会保存我所有的数据n‘同步。例如，如果我想编辑用户的电话，我将直接在用户存储上进行编辑，这将通过UI传播，其他会议引用同一个用户。我根本不用碰会议的对象。

此外，我还可能遇到这样一个问题，即我还需要返回用户的嵌套数据，比如他们的公司信息：

{userId: 1, name: 'a', phone: '1800-0111', email: 'bla@bla.com', companyId: 10}

{companyId: 10, phone: '1900-02222', name: 'ACME INC'}.

你觉得我太担心网络带宽了吗？我应该用填充的用户数据(ala‘MongoDB)返回会议吗？

或者我应该返回会议并执行一个单独的请求，在用户API端点下获取唯一的用户，比如‘/user?filterById=1，2，3’？虽然我喜欢这种方法，但我会担心速度，例如，如果我让enduser在输入框和每个输入更改事件上搜索会议，就会刷新结果(比如弹性搜索)。我认为，如果我被要求同时显示用户的信息，结果会显示得很慢。有什么想法？

是否有一个事实上的方法来解决这个问题与休息？你会有什么建议？

谢谢。

Answer 1

我不知道萤火虫，我的回答是“这取决于”。

编辑摘要:我可以选择(A)，包括直接在会议下重新安排与会者(而不是像您所做的那样进行优化)，或者(B)根本不包括它们，只提供与会者资源的URI。在我看来，选择(A)是一个合理的妥协。

如果您的目标是尽可能成为RESTful，包括两个顶级资源(meetings和allUsersIntersectedByMeetings)并不适合。

相反，您可以拥有负责返回会议的会议的/meetings集合。一种可能效率不高的网络方式是将meeting资源的链接添加到每个与会者的URL中。

这样，您的浏览器就有可能缓存它在过去已经请求过的参与者(人员)。

您可以包含参与者对象direclty，而不是链接，例如：

{ "meetings": [ { "id": 1, "attendees": [ { "id": 1, "name": "Oscar" } ] ] }

顺便说一句，"JSON“标准使用了一个includes部分，就像您最初的示例一样。我不知道这种方法是如何RESTful的。

Answer 2

将嵌套数据规范化或扁平化的一个同样好的论据是，当涉及到更新这些数据时。这是很好解释的这里。由于这是一个常见的用例，Dan创建了归一化，后来重新编写，现在由Paul维护。

但是如果您也控制了API，并且您可能将数据以规范化的形式存储在数据库中，那么在您的API端点中去规范化它只是为了在您的客户机中直接规范化它(使用正常化)是相当愚蠢的.在这种情况下，当然，如果您是唯一的消费者，只需将数据规范化，然后这样通过线路传递给您的客户。

具体地说，你会有这样的东西

GET /meetings

{
    "result": ["1", "2"],
    "entities": {
        "meetings": {
            "1": { "id": 1, "date": "2016-01-01", "attendees": [1, 2, 3] },
            "2": { "id": 2, "date": "2016-01-02", "attendees": [2, 3, 4] }
        },
        "users": {
            "1": { "id": 1, "name": "User 1" },
            "2": { "id": 2, "name": "User 2" },
            "3": { "id": 3, "name": "User 3" },
            "4": { "id": 4, "name": "User 4" }
        }
    }
}

这样的响应非常简单，可以以通用的方式合并到您的存储中。

如果有多个使用者，则可以选择normalize=true查询参数。您还可能希望将其与某种expand|include=entities,to,include查询参数结合起来。

最后，请注意JSON规范了具有通量/还原存储的规范化结构的玩得不好。

进一步读：

• https://stackoverflow.com/questions/39740883/is-there-currently-a-consensus-on-which-api-design-fits-a-react-redux-app
• https://www.reddit.com/r/reactjs/comments/5g3rht/use_归一化_或_只是_压扁_在……里面_这个_休息_空气污染指数/