最近，我深入研究了WebSockets的主题，并构建了一个利用它们的小应用程序。
现在我想知道为什么基于HTTP的API仍在使用，或者更确切地说，为什么它们仍在被提出。
据我所知，没有什么是我不能用 WS 做的，这可以通过 HTTP 实现，但反过来，我获得了很多改进。
从HTTP 驱动的后端获得比从 WS 后端获得更多好处的应用程序的真实示例是什么？
@Julian Reschke提出了很好的观点。网络是基于文档的，如果你想让你的应用程序在WWW中播放......它必须遵守游戏规则。
不过，您可以创建符合这些条件的基于 WS 的 SPA 应用程序。
-
使用 HTML5 历史记录 API，您可以更改浏览器显示的 URL，而不会导致导航。这允许您根据应用的状态在地址栏中使用不同的 URL，然后启用书签和页面历史记录。AngularJS的插件"ui-router"在这里玩得很好，如果你以编程方式更改状态，就会改变URL，反之亦然。
-
您可以使您的 SPA 可抓取。
但是，您仍然希望将HTTP用于其他一些事情，例如获取资源或视图并使用HTTP缓存机制对其进行缓存。例如，如果您有一个大型应用程序，则希望按需下载一些大视图，而不是将所有内容打包在大型主视图中。
例如，实现自己的 HTML 缓存机制以获取视图并将其缓存在本地存储中会很痛苦。此外，通过使用传统的 HTTP 请求，可以将这些视图缓存在 CDN 和其他代理缓存中。
Websocket 非常适合维护"连接"语义，以很少的延迟发送数据并随时从服务器获取推送的数据。但传统的HTTP请求仍然更适合可以从分发机制中受益的操作，如缓存，CDN和负载平衡。
关于 REST API 与 WebSocket API(我认为您的问题实际上是关于这个的(，它更像是一种便利而不是偏好。如果您的 API 每个连接的调用率很高...Websocket可能更有意义。如果您的 API 调用率较低，则使用 WebSocket 毫无意义。请记住，Websocket 连接虽然是轻量级的，但这意味着服务器中的某些内容正在被保留(即：连接状态(，如果请求速率不能证明它是合理的，则可能会浪费资源。
书签？页面历史记录？缓存？搜索引擎的可见性？
HTTP和WebSockets是两个Web工具，用于完成不同的任务。使用 HTTP，您通常实现请求/响应范例。使用 WebSocket，您通常实现异步实时消息传递范例。
有几个应用程序需要这两种范式。
您还可以尝试将 WebSockets 用于请求/响应，并使用 HTTP 进行异步实时消息传递范例。虽然前者意义不大，但后者是一种广泛的技术，在所有 WebSocket 不起作用的情况下都是必需的(由于网络中介、缺乏客户端支持等(。如果您对这个主题感兴趣，请查看我的另一个答案，它试图澄清与这些技术相关的术语：彗星现在是否已经过时了服务器发送的事件和 WebSocket？