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