我们正在开发一个浏览器扩展，它将登录用户访问的所有 URL 发送到后端 API 以进行持久化。
现在，由于发送到后端 API 的请求数量非常庞大，因此我们很困惑是通过 websocket 创建持久连接还是通过 TCP 连接（即使用 HTTP REST API 调用）来创建持久连接。
发送到后端 API 的数据不需要是实时的，因为无论如何我们都会在我们的模型中使用这些数据，而这并不要求它们是实时的。
由于以下原因，我们倾向于 HTTP REST API 调用
但同时也会有缺点
如果我们可以在使用 REST API 调用选项时遇到任何陷阱，我会很高兴听到社区的消息。
【问题讨论】：
所以首先 TCP 是传输层。无法使用原始 TCP，您必须在其之上创建一些协议。您必须为数据流赋予意义。
REST 或 HTTP 甚至 WebSockets 永远不会像在原始 TCP（甚至 UDP）之上定制设计的协议那样高效。然而，收益可能并不像人们想象的那么惊人。我实际上已经完成了一次这样的转换，我们只体验了百分之几的性能提升。正确地做起来也不容易，维护起来也不容易。当然是 YMMV。
这是为什么呢？嗯，原因是 HTTP 已经高度优化了。首先，您有“保持活动”标头，如果使用它，则可以保持连接打开。因此，默认的 HTTP 机制在使用时已经保持连接。其次，HTTP 默认处理正文压缩，并且使用 HTTP/2 它还处理标头压缩。使用 HTTP/3，您甚至可以更高效地使用 TLS，并在网络不稳定（例如移动设备）的情况下提供更好的支持。
另一件事是，由于您不需要实时数据，因此您可以进行缓冲。因此，您不会在每次数据可用时都发送数据，而是在几秒钟、几分钟甚至几小时内收集数据，然后一次性发送所有数据。使用这种方法，HTTP 和自定义协议之间的差异将更加不明显。
总而言之：我建议您从最简单的解决方案开始，在您的情况下，它似乎是 REST。设计您的代码，以便尽可能简单地转换到其他协议。如果需要，稍后进行优化。始终测量。
顺便说一句，您的扩展程序存在许多有效的隐私和安全问题。例如，我很惊讶你根本没有提到 TLS。这很重要，不仅因为安全，还因为性能：建立 TLS 连接不是免费的（虽然一旦建立，加密对性能影响不大）。
【讨论】：
把我的不适放在一边（隐私，有人吗？）...
假设您的扩展程序整理信息，您可能会考虑在每次浏览器启动/退出时“推送”到服务器，然后每隔一小时左右再次推送一次（这些天用户几乎不会完全使用他们的浏览器）......这将使REST 更符合逻辑。
如果您不在客户端整理信息，您可能更喜欢实时推送数据的 WebSocket 实现。
但是，无论您决定如何，您还希望将 API 与传输层分离。
这意味着（忽略身份验证范例）WebSockets 和 REST 实现看起来大致相同，并被路由到包含实际业务逻辑的相同函数...您也可以从脚本或终端调用的函数.就 API 实现而言，网络层的细节应该是无关紧要的。
最后一点：我永远不会故意安装一个会收集这么多数据的扩展程序。特别是因为 URL 通常包含私有信息（用于 REST API 路由）。如果您想参与创建此类产品，请重新考虑...如果我们不构建使之成为可能的工具，他们就不会侵犯我们的隐私。
【讨论】：