用 WebSocket 替换 API 调用有什么缺点？答案

【问题标题】：What could be the drawbacks of replacing API calls with WebSockets?用 WebSocket 替换 API 调用有什么缺点？
【发布时间】：2018-07-17 06:26:03
【问题描述】：

所以我计划构建一个单页应用程序。在那个应用程序中，会有很多 API 调用，而且非常频繁，超出我们的预期。

所以我们正在考虑前面的 API 调用并将其完全替换为 WebSockets。所以我们计划如何完成这项工作如下：

我们为客户端可以请求的每个资源指定一个特殊的代码（或套接字消息类型）。
客户端通过 websocket 连接到服务器。
对于客户端想要的每个资源/数据，它会使用预定义的代码向服务器发送一条消息。
服务器处理请求并将响应发送回客户端。
客户端和服务器保持连接打开，以后的任何请求都通过同一个套接字进行通信。

我们希望通过这种方法减少开销和延迟，但这是一个正确的假设吗？另外，使用这种机制有什么缺陷？

【问题讨论】：

在我们的场景中，我们将失去特定 API 提供的所有异常处理和供应商错误报告。我不知道这是否特别适用于你。我们的解决方案类似的问题是转移到事件驱动设计并将我们的 API 调用排队等待守护进程处理。
但是，如果客户希望尽快得到回复，您就不能将所有呼叫排队。但是我同意日志记录和其他长期运行的东西排队是要走的路。
如果你走这条路，你可能需要考虑 Actor 模型
@AyushGupta 如果您的 API 端点允许并发连接，您可以使用守护程序在它们进入时将其关闭。在某些情况下我们能够做到这一点，而在其他情况下端点获胜不允许它，在这种情况下，我们已经能够将一些捆绑到有效负载中。有很多变量需要考虑。
Websocket vs REST when sending data to server的可能重复

标签： rest websocket

【解决方案1】：

如果您正在编写消息传递应用程序或游戏，则最好使用 WebSocket。如果您的应用经常访问数据库，您可以考虑 Server Sent Events

WebSockets 在客户端和服务器之间进行双向通信。您可能不一定需要 websocket。

WebSockets 可能看起来像 HTTP，但只是在开始时。它不是 HTTP。在协议的设计中可能没有考虑到可能的副作用。它们在用户与页面交互期间保持服务器上的连接打开。这将增加对服务器的需求，这意味着您将始终需要向外扩展而不是向上扩展。如果没有消息应用或游戏，我相信 WebSockets 是一个不太经济的选择。