SPA：仅使用WebSocket。为什么不呢？

我正在重新设计一个web应用程序，它以前在服务器端被呈现为一个单页应用程序，并开始阅读WebSocket。web应用程序将使用套接字将新记录和/或消息推送到客户端。我一直在想，为什么大多数使用套接字的页面不能通过套接字处理所有的通信。大多数情况下，除了websocket之外，还有RESTful后端。让客户端通过套接字查询新资源是个坏主意吗？如果是这样的话，为什么RESTful api更容易与其他设备一起使用呢

我可以想象，如果网络连接有点像在移动设备上那样糟糕，那么使用WebSocket可能不是最好的主意，但如果与web的连接合理，这可能会很好

我发现了这个相关的问题，但它是从2011年开始的，似乎有点过时：

---

不，这不是个坏主意。实际上，我在一个应用程序中工作，该应用程序使用WebSocket连接进行所有数据交互，web服务器只处理对资源、不同语言、不同维度下的视图的请求。。等等

---

问题可能是缺少基于持久连接的框架/工具。多年来，大多数框架（前端和后端）都是围绕请求/响应模型设计和构建的。这种方法的转变可能并不容易接受。

几年后再回到这个问题，我想指出几个方面来说明，通过WebSocket进行交流确实有其缺点：

• 没有对压缩的通用支持。您可以轻松地将web服务器配置为压缩http请求，多年来浏览器一直乐于接受压缩响应，但是对于web套接字来说，这仍然不是那么容易（尽管情况有所改善）
• 客户机框架通常是基于rest等常用标准构建的。离框架期望越远，可用的插件或功能就越少
• 在浏览器中缓存不是那么容易。到目前为止，这已经走了很长一段路，进入了离线可用性和PWA领域
• 当使用仅由一部分用户使用的技术时，它更有可能发现新的bug，或者bug修复可能需要更长的时间。如果不是虫子，在拐角处可能会有一个边缘案例。这本身不是一个问题，而是一个需要注意的问题。如果遇到这些问题，它们通常很容易占用相当多的时间来修复或解决

---

是的。仅通过WebSocket与后端进行SPA对话是一种可行的方法。您可能会感兴趣，它提供了WebSocket上常用的抽象：远程过程调用（RPC，类似于Ajax需求）加上发布和订阅。在一个基于WebSocket的子目录中。披露：我是WAMP的原始作者。对，我发现了WAMP，我认为它很棒，但我们决定设计我们自己的协议。我们的应用程序作为FSM工作，因此没有明确的订阅。例如，服务器根据您的状态决定发送给您的内容。什么是FSM@vtortolaFSM是有限状态机的常用缩写。我想我听过FSM比有限状态机更经常地说。难道一个

秒WebSocket Extensions:deflate frame

不是用来实现压缩的吗？是的，也许我在这方面的知识有点过时了。我试图找到有关当前浏览器支持的更多信息，但在快速搜索后无法找到。如果你能找到关于这方面的好信息，如果你也能将其添加到这里，我将不胜感激。基本上，通过双向WebSocket提供我想要的静态内容，并仅交换纯动作/事件。目前正在寻找论据，如果我没有外部API使用者，为什么还要维护REST API。@Dzintars我个人的建议是：如果您确实需要通过网络获取数据，请使用大多数web使用的方法。如果您有充分的理由使用其他东西（如WebSocket），那么这样做可能是有意义的。然而，很有可能您也会注册一些边缘案例、浏览器错误和一些解决办法来修复一些奇怪的事情。如果你的好理由仍然更重要，那就去做吧。至于我：我目前正在花一些时间最终摆脱WebSocket作为主要的通信手段。