最近我深入研究了WebSockets的主题并构建了一个利用它们的小应用程序。
现在我想知道为什么仍在使用基于HTTP的API'，或者更确切地说，为什么它们仍然被提出。
据我所知，通过HTTP可以实现WS无法做到的任何事情，但另一方面我获得了很多改进。
从HTTP驱动的后端获取比从WS后端获得更多好处的应用程序的真实示例是什么？
答案 0 :(得分：3)
但是，您仍然可以创建符合这些要求的基于WS的SPA应用程序。
使用HTML5历史记录API，您可以change the URL in shown by the browser without causing navigation。这样，您就可以在地址栏中显示不同的网址，具体取决于应用的状态，然后启用书签和网页历史记录。插件＆＃34; ui-router＆＃34;对于AngularJS在这里播放得非常好，如果以编程方式更改状态则更改URL，反之亦然。
但是您仍然希望将HTTP用于其他一些事情，例如获取资源或视图并使用HTTP缓存机制缓存它们。例如，如果您有一个大型应用程序，您希望按需下载一些大视图，而不是将所有内容打包在一个大的主视图中。
实现自己的HTML缓存机制以获取视图并将其缓存在本地存储中会很麻烦。此外，通过使用传统的HTTP请求，这些视图可以缓存在CDN和其他代理缓存中。
Websockets很适合维护＆＃34;连接＆＃34;语义，以很少的延迟发送数据，并随时从服务器获取数据。但传统的HTTP请求对于可以从分发机制中受益的操作来说仍然更好，例如缓存，CDN和负载平衡。
关于REST API与WebSocket API（我认为你的问题实际上就是这个问题），它更像是一种便利而不是偏好。如果您的API每个连接的通话率很高...... websocket可能更有意义。如果您的API获得较低的通话率，则使用WebSocket没有意义。请记住，Websocket连接虽然很轻，但它意味着服务器中的某些东西被保留（即：连接状态），如果请求率不合理，可能会浪费资源。
答案 1 :(得分：2)
书签？页面历史？缓存？对搜索引擎的可见性？
答案 2 :(得分：0)
HTTP和WebSockets是两个用于完成不同任务的Web工具。 使用HTTP，您通常会实现请求/响应范例。 使用WebSockets，您通常会实现异步实时消息传递范例。
有几个应用程序需要这两种范例。
您还可以尝试使用WebSockets进行请求/响应，并将HTTP用于异步实时消息传递范例。虽然前者没有多大意义，但后者是一种普遍的技术，在WebSocket无法工作的所有情况下都是必需的（由于网络中介，缺乏客户端支持等）。如果您对这个主题感兴趣，请查看我的其他答案，该答案试图澄清与这些技术相关的术语：Is Comet obsolete now with Server-Sent Events and WebSocket?