我正在重新设计一个web应用程序，该应用程序以前已被渲染为服务器端到单页应用程序，并开始阅读有关websockets。web应用程序将使用套接字将新记录和/或消息推送到客户端。我一直想知道为什么大多数使用套接字的页面不处理套接字上的所有通信。大多数情况下，除了websocket之外还有RESTful后端。让客户端通过套接字查询新资源是个坏主意吗?如果是这样，为什么呢?难道不是因为RESTful api可能更容易与其他设备一起使用吗?
我可以想象，使用websockets可能不是最好的主意，在情况下，网络连接有点糟糕，就像在移动设备上一样，但这可能会工作得很好与一个合理的网络连接。
我发现了这个相关的问题，然而它是从2011年开始的，似乎有点过时:Websocket API取代rest API ?
几年后回到这个问题，我想指出几个方面来说明通过websockets进行所有通信确实有其缺点:
- 没有通用的压缩支持。你可以很容易地配置你的web服务器来压缩http请求，浏览器已经很高兴地接受压缩响应多年了，但是对于web套接字来说，它仍然不是那么容易(即使情况有所改善)
- 客户端框架通常建立在rest等常用标准之上。离框架的期望越远，可用的插件或特性就越少。 在浏览器中缓存
- 就不那么容易了。到目前为止，这已经走了很长一段路，到达了离线可用性和pwa的领域。
- 当使用仅由一小部分用户使用的技术时，它更有可能发现新的错误，或者错误可能需要更长的时间来修复。如果不是bug，可能会在某个角落出现边缘情况。这本身并不是一个问题，但需要注意。如果一个人遇到这些事情，他们通常很容易花一些时间来修复或解决。
不，这不是个坏主意。实际上，我在一个使用WebSocket连接进行所有数据交互的应用程序中工作，web服务器只处理对不同语言，维度下的资源，视图的请求。等
问题可能是缺乏基于持久连接的框架/工具。多年来，大多数框架(前端和后端)都是围绕请求/响应模型设计和构建的。方法的转变可能不那么容易接受。