将数据发送到服务器时Websocket与REST

Question

背景

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

问题

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

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

Answer 1

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

使用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 vs rest API for real time data?

Ajax vs Socket.io

根据您的要求添加评论：

听起来你好像有人告诉你＆＃34;对＆＃34;这样做的方式。有理由选择一种方式而不是另一种方式。如果这些原因都不会强迫你采用一种方式而不是另一种方式，那么它只是一种架构选择，你必须了解你正在做的事情的整个背景，并决定哪种架构选择对你更有意义。如果您已经拥有可靠建立的webSocket连接，并且REST的所有优势都不适用于您的情况，那么您可以优化＆＃34;效率＆＃34;并通过webSocket连接将数据发送到服务器。

另一方面，如果您希望服务器上有一个简单的API，可以通过其他客户端的Ajax调用来访问，那么您希望您的服务器通过REST支持此操作，这样就可以了这些其他客户端最简单的方法就是执行这一操作。所以，这一切都取决于你的要求驱动你的方向，如果没有特定的驱动理由，你可以自己做一个建筑选择。