可以将 HTTP REST API 用于聊天应用程序吗？

Question

我们正在 Android 上构建一个聊天应用程序。我们正在考虑使用 HTTP REST API 发送出站消息。想知道与使用 WebSockets 或 XMPP（这似乎更像是传输聊天消息的事实上的标准）相比，它是一种好方法还是有什么缺点？

我能想到的一些优点/缺点是：

• HTTP 端点很容易在服务器端水平扩展（这是主要问题）
• 与 HTTP 相比，Websockets 的学习曲线更加陡峭

• 与 WebSocket 相比，HTTP 消息的负载更大

根据本文档，似乎 Facebook 最初也使用 AJAX 来处理聊天消息：

https://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf

Answer 1

我认为 REST 方法可以用于聊天。让我们假设：

• http://chat.example.com/conversations 引用所有对话
  • GET 获取列表
  • POST 创建一个新的
• http://chat.example.com/conversations/123 参考对话#123
  • GET 获取此对话中的消息
  • POST 在对话中添加一条消息

如果我理解正确，您的问题是关于最后一点。

一旦客户端向http://chat.example.com/conversations/123发布了一条出站消息，它将关闭http连接。

缺点是在这种情况下根本无法接收入站消息。您将需要一个不同的频道（可能只是 Google cloud messaging）。

相反，WebSockets 和 XMPP 保持连接处于活动状态，因此它们可以毫无延迟地接收消息。但是它们的缺点确实是，这代表了服务器的成本，就可扩展性而言；以及客户在电池使用方面的成本。

在服务器上：

• 套接字是一种相对稀缺的资源
• 如果客户端有打开的连接，则无法移动客户端以进行负载平衡（但您真的可以移动客户端吗？这取决于层的责任）

在客户端：

• 维护网络连接非常昂贵。 1 秒网络 ≈ 5 分钟睡眠。
• XMPP librairies are not necessarily working very well on Android。 我不知道support of WebSockets on android。

Answer 2

我们可以使用 REST API 进行聊天消息传递，但恕我直言，XMPP 是更好的选择。让我们考虑一下 XMPP 可以提供什么。

XMPP 除了支持 TCP 传输外，还提供 HTTP（通过 polling 和 binding）和 websocket 传输。阅读XMPP via HTTP and WebSocket transports

从 XMPP 的角度了解每种传输方式的优缺点会很有趣。

XMPP 可以通过两种方式使用 HTTP：polling[18] 和 binding。

XMPP over HTTP 轮询

投票 方法，现在已弃用，本质上意味着消息存储在 服务器端数据库被定期获取（和发布） XMPP 客户端通过 HTTP 'GET' 和 'POST' 请求。

---

XMPP over HTTP 绑定 (BOSH)

绑定方法被认为比轮询方法中的常规 HTTP 'GET' 和 'POST' 请求更有效，因为与其他 HTTP 轮询技术相比，它减少了延迟和带宽消耗

但是，这也带来了一个缺点，即套接字会长时间保持打开状态，等待客户端的下一个请求

绑定方法，使用同步 HTTP 上的双向流实现 (BOSH)，[19] 允许服务器在收到消息后立即向客户端推送消息 被发送。 这种推送模式的通知比 民意调查，其中许多民意调查没有返回新数据。

如果我们了解the BOSH technique 的工作原理，那就太好了。

BOSH 采用的技术，有时称为“HTTP long polling”，相比其他 HTTP 减少了延迟和带宽消耗 投票技术。当客户端发送请求时，连接 经理没有立即回复；相反，它拥有 请求打开，直到它有数据实际发送到客户端（或 商定的不活动时间已过）。那么客户端 立即向连接管理器发送一个新请求，继续 长轮询循环。

如果连接管理器没有任何数据要发送给客户端 在经过商定的时间长度 [12] 后，它会发送一个带有 空的 。这与空白保持活动的目的相似 或 XMPP Ping (XEP-0199) [13]；它有助于保持套接字连接处于活动状态 这可以防止一些中介（防火墙、代理等） 默默地放下它，并有助于在合理的范围内检测中断 时间。

---

XMPP over WebSocket 绑定

XMPP 支持 WebSocket 绑定，这是一种更高效的传输方式

一种可能更有效的实时消息传输方式是 WebSocket，一种提供双向、全双工的网络技术 单个 TCP 连接上的通信通道。 XMPP 结束 WebSocket 绑定在 IETF 提议的标准 RFC 7395 中定义。

说到学习曲线，是的，您可能很想使用 REST API，但现在有几个资源可供您了解 Android and XMPP 和 XMPP server softwares，您可以使用它们来运行您自己的 XMPP 服务通过 Internet 或局域网。在决定架构之前花费这些精力是值得的。

Answer 3

不建议将 HTTP Rest API 用于聊天或类似的实时应用程序。

一些概述...

聊天客户端要求

1. 好友列表获取

2. 查看在线/离线好友

3. 实时获取聊天消息并发送消息。

4. 接收送达/阅读等通知

第 1 点是您启动聊天客户端后的一次性工作，因此可以通过简单的休息调用来完成，因此不需要复杂的开销。

如果是 p2p 客户端，其余所有点都需要持续检查来自服务器或其他部分的数据。这将使您创建长或短轮询休息调用以观察新数据或其他更新。

HTTP Rest 客户端问题

这不是一种保持活动的通信类型，因此您必须建立多个 HTTP 连接，这将产生如此多的开销，以至于它会变得过于滞后。因为在 HTTP 调用中重新连接非常昂贵。

Web 套接字或 XMPP 它们是双工通信模式，非常擅长处理增量数据推送，并且您无需再次创建新的 HTTP 连接，因此它提供了非常流畅的性能。

另一种解决方案 万一你被一些遗留系统卡住了，你必须使用rest API模式。

试试 CometD，它是 WebSockets 和 ajax 轮询的混合方法，它将为您提供近乎实时的通信以及通过回退到 ajax 轮询机制在不支持 WebSockets 的客户端上工作。此外，它使用各种优化来避免一次又一次地重新连接。

CometD link

您也可以尝试 Socket.io，这也是解决此类用例的一项了不起的技术

Answer 4

简答号

我不会开始一个新项目或建议开始一个新项目（因为您提到重新开始）需要依赖 HTTP 的实时双向通信 - 作为无状态协议。您可能会对连接保持活动感到欣慰，但不能保证。

您的+ HTTP endpoint is easy to scale horizontally on server side pro 在 HTTP 用作请求和响应样式并且被认为是无状态的情况下是专业的。当您本质上需要保持连接处于活动状态时，它变得有些没有意义（尽管并非完全如此）。

HTTP 确实提供了您在此处未提及的另一个好处。

• 当其他端口可能被阻止时，HTTP 很容易处理公司防火墙代理。

这是其他人提到的 WebSockets 或 XMPP over HTTP 的成功率更高的地方。

Answer 5

这取决于。您认为您的应用程序是“实时聊天”吗？您需要存在指示器还是打字指示器？诸如此类的功能需要持续连接。但是还有另一组聊天应用程序，您可以将其描述为启用了“应用内消息传递”。这些应用程序将对话和对话列表存储在某种后端；只需在另一台设备上安装该应用程序并登录，您就会在此类应用程序上看到您的对话。这些应用程序没有任何存在指示符或活跃感。

虽然我没有使用 XMPP 实现任何应用程序，但看起来就消息持久性而言，你会发现使用 XMPP（开箱即用）的最持久性是持久性直到交付，类似于 SMS。也许您可以通过捕获通过的节并将它们存储在您自己的数据库中来为 XMPP 构建存储/恢复机制。但是，如果您不需要完整的“聊天”体验，使用数据库、HTTP 服务和推送通知（通知更新的线程）似乎是具有消息传递功能的应用程序的可靠途径——我打算在 iOS 和我现在自己的 Android 应用程序。

如果您为此找到任何好的开源架构/API 设计，请告诉我。