具有从服务器到客户端的主动推送通知的 REST API

Question

问题描述

我正在开发一个 Xamarin 应用程序，该应用程序使用用 Python 烧瓶编写的 REST API。

Xamarin 应用程序提供虚拟购物清单，用户可以在其中协作购买共享清单上的商品。

为了改善用户体验，我希望能够主动通知用户列表中已完成的项目。

可能的解决方案：

来自客户端的同步 API 轮询

通知由 API 存储在关系数据库中，并有一个标志，指示用户是否已收到通知。

API 有一个端点GET /users/:user_id/notifications/，用于查询数据库中的通知并返回带有这些通知的 JSON 响应。

好处

• 实施起来相当简单

问题

• 同步轮询会产生大量的 http 请求

• API 服务保持无状态，使用负载均衡器更容易进行水平扩展

API 上的 Websocket 端点

API 有一个端点POST /users/:user_id/notifications/register，它在客户端和 API 之间创建 websocket 连接。

连接存储在一个全局数组中，其中每个条目将一个客户端 ID 映射到一个 websocket 连接。

创建新通知时，端点通过将通知的所有者 ID 与字典条目进行比较，在连接字典中进行查找。通知通过 websocket 发送给适当的用户。

通知像第一种方法一样存储在数据库中。

当用户调用端点时，将首先建立一个新的 websocket 连接，成功后 API 将所有看不见的通知从数据库发送给用户。

好处

• API 可以异步推送通知给客户端

问题

• 当用户终止 websocket 连接时，他的字典条目将保留
• 为每个用户保留一个 websocket 连接会永久增加 API 的额外开销
• API 的横向扩展更困难，因为服务不再是无状态的（Websocket 连接信息保存在

兔MQ

API 使用 RabbitMQ 服务向客户端发送通知。每个客户端都使用订阅自己的通知队列来防止消息广播。

好处

• API 保持无状态

问题

• 当用户离线时需要重新发送通知到交易所

• 队列数量急剧增加

• RabbitMQ 服务的额外费用

• 多个用户同时在线时，RabbitMQ 服务的临时负载较高

最后的话

听听别人的意见会很有趣。

我相信从后端服务向客户端主动分发通知是一个非常常见的用例。

最好的，D

Answer 1

我可以推荐一种不同的 API 方法来提供 JSON，称为GraphQL

它支持由 GraphQL API 服务器（使用 Web 套接字）推送的订阅功能。
如今，GraphQL 被认为比 RESTful API 更好，因为它非常灵活，您可以通过一次查询准确获取所需的数据。