最近我深入研究了 WebSockets 的主题并构建了一个使用它们的小型应用程序。
现在我想知道为什么仍在使用基于 HTTP 的 API，或者更确切地说，为什么仍在提出它们。
据我所知，WS 没有什么是我不能通过 HTTP 实现的，但反过来我获得了很多改进。
如果应用程序从 HTTP 支持的后端比从 WS 中获得更多好处，那么现实世界的示例是什么？
【问题讨论】：
标签： http web-applications web websocket
HTTP 和 WebSockets 是两个 Web 工具，用于完成不同的任务。 使用 HTTP，您通常会实现请求/响应范例。 使用 WebSockets，您通常可以实现异步实时消息传递范例。
有几个应用程序需要这两种范式。
您还可以尝试使用 WebSockets 进行请求/响应，并使用 HTTP 进行异步实时消息传递范例。虽然前者意义不大，但后者是一种广泛使用的技术，在所有 WebSockets 不工作的情况下都是必需的（由于网络中介、缺乏客户端支持等）。如果您对此主题感兴趣，请查看我的另一个答案，它试图澄清与这些技术相关的术语：Is Comet obsolete now with Server-Sent Events and WebSocket?
【讨论】：
@Julian Reschke 提出了很好的观点。 Web 是基于文档的，如果您希望您的应用程序在 WWW 中运行……它必须符合游戏规则。
不过，您可以创建符合这些要求的基于 WS 的 SPA 应用程序。
使用 HTML5 历史 API，您可以change the URL in shown by the browser without causing navigation。这使您可以根据应用程序的状态在地址栏中使用不同的 URL，然后启用书签和页面历史记录。 AngularJS 的插件“ui-router”在这里玩得很好，如果您以编程方式更改状态，则会更改 URL，反之亦然。
但您仍然希望将 HTTP 用于其他一些事情，例如获取资源或视图并使用 HTTP 缓存机制缓存它们。例如，如果您有一个大型应用程序，您希望按需下载一些大型视图，而不是将所有内容打包在一个大型主视图中。
例如，为 HTML 实现自己的缓存机制以获取视图并将它们缓存在本地存储中会很痛苦。此外，通过使用传统的 HTTP 请求，这些视图可以缓存在 CDN 和其他代理缓存中。
Websocket 非常适合维护“连接”语义、以极短的延迟发送数据并随时从服务器获取推送数据。但是传统的 HTTP 请求仍然更适合可以从分发机制中受益的操作，例如缓存、CDN 和负载平衡。
关于 REST API 与 WebSocket API（我认为您的问题实际上是关于这个的），它更多的是方便而不是偏好。如果您的 API 每个连接的调用率很高...... websocket 可能更有意义。如果你的 API 调用率很低，那么使用 WebSocket 就没有意义了。请记住，一个Websocket连接，虽然它是轻量级的，但它意味着服务器中的某些东西正在被持有（即：连接状态），如果请求率不合理，它可能会浪费资源。
【讨论】：
书签？页面历史？缓存？对搜索引擎的可见性？
【讨论】：