为什么我们仍然使用HTTP而不是WebSockets来构建Web应用程序？

Question

最近我深入研究了WebSockets的主题并构建了一个利用它们的小应用程序.

现在我想知道为什么仍在使用基于HTTP的API',或者更确切地说,为什么它们仍然被提出.

据我所知,通过HTTP可以实现WS无法做到的任何事情,但另一方面我获得了很多改进.

从HTTP驱动的后端获取比从WS后端获得更多好处的应用程序的真实世界示例是什么？

Answer 1

@Julian Reschke 提出了很好的观点。Web 是基于文档的，如果您希望您的应用程序在 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 连接虽然是轻量级的，但这意味着服务器中正在保留某些内容（即：连接状态），如果请求率不合理，则可能会浪费资源。

Answer 2

添加书签？页面历史记录？缓存？搜索引擎的可见性？