向服务器发送数据时 Websocket 与 REST

背景

我们正在编写一个类似 Messenger 的应用程序。我们已将 Websockets 设置为收件箱和聊天。

Question

我的问题很简单。什么时候有什么优点和缺点从客户端向服务器发送数据使用 REST 而不是 Websocket？ （我现在对更新不感兴趣。）

我们知道 REST 在消息大小方面具有更高的开销，并且 WS 是双工的（因此始终开放）。那么其他我们没有记住的事情呢？

以下是我所知道的权衡的摘要。

使用 webSocket 的原因：

1. 您需要/想要服务器推送数据。
2. 您需要定期从客户端向服务器发送大量小数据。使用 webSocket 可以显着减少每次传输的开销。

使用 REST 的原因：

1. 您想要使用为 REST 而不是为 webSocket 构建的服务器端框架或模块（例如身份验证、速率限制、安全性、流式传输等）。
2. 您不会经常从客户端向服务器发送数据，因此始终保持 webSocket 连接打开的服务器端负担可能会降低服务器的可扩展性。
3. 您希望您的客户端在不活动期间长连接 webSocket 可能不可行的地方运行（可能是移动设备）。
4. 您希望您的客户端在不支持 webSocket 的旧浏览器中运行。
5. 您希望浏览器强制执行同源限制（这些限制针对 REST Ajax 调用强制执行，但不针对 webSocket 连接强制执行）。
6. 您不想编写代码来检测 webSocket 连接何时断开，然后自动重新连接并处理回退以及处理电池使用问题等移动问题......
7. 您需要在存在可能不支持长时间运行的 webSocket 连接的代理或其他网络基础设施的情况下运行。
8. 如果您想要内置请求/响应。REST 就是请求/响应。 WebSocket 不是——它是基于消息的。来自 webSocket 的响应是通过发回消息来完成的。返回的消息本身并不是对任何特定请求的响应，它只是发送回的数据。如果您想要使用 webSocket 进行请求/响应，那么您必须自己构建一些基础设施，在其中将 id 标记到请求中，并且该特定请求的响应包含该特定 id。否则，如果同时有多个请求，那么您不知道哪个响应属于哪个请求，因为所有数据都通过同一连接发送，并且您将无法将响应与请求进行匹配。
9. 如果您希望其他客户端能够通过 Ajax 调用来执行此操作。

因此，如果您已经有了 webSocket 实现，并且对 REST 减轻的问题没有任何疑问，并且对 REST 可能更好的任何原因不感兴趣，那么就坚持使用您的 webSocket 实现。

相关参考：

websocket 与 REST API 的实时数据比较？ https://stackoverflow.com/questions/28613399/websocket-vs-rest-api-for-real-time-data/28618369#28618369

Ajax 与 Socket.io https://stackoverflow.com/questions/30319618/ajax-vs-socket-io/30334848#30334848

根据您的要求添加评论：

听起来你好像在期待有人告诉你“正确”的做法。选择一种方式而不是另一种方式是有原因的。如果这些原因都没有迫使您采取某种方式与另一种方式相比，那么这只是一种架构选择，您必须考虑您正在做的事情的整个上下文，并决定哪种架构选择对您更有意义。如果您已经建立了可靠的 webSocket 连接，并且 REST 的任何优点都不适用于您的情况，那么您可以优化“效率”并通过 webSocket 连接将数据发送到服务器。

另一方面，如果您希望服务器上有一个简单的 API，可以通过其他客户端的 Ajax 调用来访问，那么您希望您的服务器通过 REST 支持此操作，这样对于其他客户端来说这将是最简单的来执行这一操作。因此，这一切都取决于您的需求驱动您朝哪个方向发展，如果没有特定的驱动原因选择一种方式或另一种方式，您只需自己做出架构选择即可。