如何使用Websockets更新REST API请求状态

Question

我使用基于REST API的内部AngularJS SPA,问题是一些REST请求会持续很长时间(约5-10秒).

它是ridiciolus,但它没有任何关系 - 服务器需要从不同的源获取大量数据并在响应之前将它们一起数学.

很好的解决方案是向用户显示请求状态,这里我们来到WebSockets.

显示给用户的请求状态示例

但是有一堆问题.

目前还不清楚如何让API用户发送请求以通知其状态.可能的解决方案是使字典"API客户端" - "Websocket连接",但它可能会在每次重新连接时爆炸并导致内存泄漏.不是吗？

也许解决方案是将整个REST API更改为Websockets.但它在这里看起来很多工作,但我仍然需要重新发明像缓存这样的东西.

从任何角度看它都是一团糟.这里有什么更好的解决方案？

Answer 1

最好同时提供REST和Websocket,因此网页可以使用websocket和自动客户端,而不支持websocket并仍然使用API.您可以异步处理这些请求,并使用REST异步模式.

休息:

客户端向API发送请求.
API获取请求并:
- 为此处理任务创建唯一ID.
- 在数据存储中记录此任务的详细信息.
- 向消息总线发送消息,请求处理该id的任务.
- 返回HTTP 202 Accepted带有Location标头的队列端点/queue/<taskid>,提供任务的状态.
客户端获取响应,并且可以Location定期轮询标头中指示的端点上的此类处理状态.
如果仍未处理任务,则返回队列端点HTTP 202 Accepted.
消息总线另一侧的后台工作人员,选择消息并:
- 转到数据存储以获取该任务ID的详细信息.
- 做处理.
- 完成后,使用该ID更新任务的状态.
此时,队列端点返回HTTP 303 See Other一个Location标头,该标头将客户端重定向到处理结果的位置.

在会话开始时建立websocket连接.
websocket服务器将传入消息转换为消息总线中的订阅操作,并将订阅消息转换为websocket中的消息.例子:
- 如果您使用的是Redis.
- 如果您使用的是RabbitMQ.
在REST步骤3中,不使用时间间隔轮询,而是使用websocket发送应用程序定义的消息以订阅此类任务ID的更改.确保您既可以知道如何从Location标题中获取任务ID ,也可以只在另一个标题中提供任务ID.
websocket服务器应该向服务总线指示这样的连接订阅了标识该任务id的变化的主题.
当后台工作程序完成数据处理后,在更新任务状态后,还会向服务总线发出一条消息,其中包含标识该任务ID的主题.
websocket服务器将获取消息,然后将其发送到客户端.
然后,客户端可以请求队列端点找出处理结果的位置.您也可以通过websocket发送该位置,但根据我的经验有时很困难,因为websocket服务器可能是一个简单的Windows服务,不了解URL或资源位置.