聊天应用程序使用HTTP REST API可以吗?

我们正在Android中构build一个聊天应用程序。 我们正在考虑使用HTTP REST API发送出站消息。 想要知道它是一个很好的方法,还是比使用WebSockets或XMPP(这似乎更像是事实上的标准传输聊天消息)的缺点?

我能想到的一些优点/缺点是:
+ HTTP端点很容易在服务器端横向扩展(这是一个主要的问题)
+与HTTP相比,Websockets的学习曲线更陡峭
– 与websocket相比,HTTP消息将具有更大的有效负载

按照这个文档,Facebook甚至使用AJAX来处理聊天消息:

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

Solutions Collecting From Web of "聊天应用程序使用HTTP REST API可以吗?"

我们可以使用REST API进行聊天消息,但恕我直言,XMPP是一个更好的select。 让我们来考虑一下XMPP所能提供的。

支持TCP传输的XMPP还提供HTTP(通过轮询绑定 )和websocket传输。 通过HTTP和WebSocket传输读取XMPP

从XMPP的angular度来理解每个交通工具的利弊是很有意思的。

XMPP可以通过两种方式使用HTTP: 轮询 [18]和绑定

基于HTTP轮询的XMPP

轮询方法现在已经被弃用了,这意味着存储在服务器端数据库上的消息正在被XMPP客户端通过HTTP'GET'和'POST'请求定期获取(和发布)。


XMPP over HTTP绑定(BOSH)

在轮询方法中,绑定方法被认为比常规HTTP“GET”和“POST”请求更高效,因为它比其他HTTP轮询技术减less了延迟和带宽消耗

但是,这也造成套接字长时间处于打开状态,等待客户的下一个请求

使用双向stream同步HTTP( BOSH )[19]实现的绑定方法允许服务器在发送消息时立即将消息推送到客户端。 这种通知的推送模式比轮询更有效率,在这种轮询中,许多轮询都不会返回新的数据。

如果我们了解BOSH技术的工作原理,这将是一件好事。

BOSH采用的技术有时被称为“HTTP长轮询”,与其他HTTP轮询技术相比,减less了延迟和带宽消耗。 当客户端发送请求时,连接pipe理器不会立即发送响应; 而是保持开放的请求,直到它有实际发送给客户的数据(或已达到约定的不活动时间长度)。 客户端然后立即发送一个新的请求到连接pipe理器,继续长轮询循环。

如果连接pipe理器没有任何数据要发送到客户端达到一定的时间后[12],它会发送一个空的响应。 这与空白保留或XMPP Ping(XEP-0199)[13]的用途类似。 它有助于保持套接字连接的活动,防止一些中间人(防火墙,代理等)无声无息地丢弃它,并有助于在合理的时间内检测到中断。


通过WebSocket绑定的XMPP

XMPP支持WebSocket绑定,这是一个更高效的传输

实时消息传输可能更高效的传输方式是WebSocket,这是一种通过单个TCP连接提供双向全双工通信信道的Web技术。 XPSP over WebSocket绑定在IETF提出的标准RFC 7395中定义。

说到学习曲线,是的,您可能会习惯使用REST API,但是现在有几个可以学习Android和XMPP的资源,以及可以用来运行您自己的XMPP服务的XMPP服务器软件 ,可以通过互联网或在局域网上。 在决定你的体系结构之前,花费这个努力是值得的。

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

一些概述..

聊天客户的要求

  1. 好友列表获取

  2. 检查在线/离线的朋友

  3. 实时获取聊天消息并发送消息。
  4. 接收送货/阅读等通知

第一点是您开始聊天客户端后的一次性工作,所以可以通过简单的rest调用完成,所以没有复杂的开销。

如果是p2p客户端,所有点都需要持续检查服务器或其他部分的数据。 这将使您创build长轮询或短轮询rest电话来观看新的数据或其他更新。

HTTPrest客户端的问题

这不是一个保持活动types的通信,因为你将不得不做多个http连接,这将有太多的开销,它会变得过于laggy。 由于重新连接在HTTP调用中的代价非常高昂。

** Web套接字或XMPP **它们是双工通信模式,并且非常善于处理增量数据推送,并且不会再创build新的http连接,因此可以提供真正stream畅的性能。

另一种解决scheme如果您遇到了一些遗留系统,而您必须使用其余的api模式。

试试CometD它是一种混合的websockets和ajax轮询方法,它可以给你提供接近实时的通信,并且可以在不支持websocket的客户端上工作,从而回退到ajax轮询机制。 它也使用各种优化来避免重新连接。

CometD链接

你也可以尝试Socket.io ,这也是一个了不起的技术来解决这种用例

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

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

一旦客户已经向http://chat.example.com/conversations/123发布了一条outboud消息,它将closureshttp连接。

缺点是在这种情况下接收入站消息是不可能的。 你将需要一个不同的渠道(也许只是谷歌云消息 )。

相反,WebSockets和XMPP保持连接的活跃,因此他们可以毫不拖延地接收消息。 但是它们两者的缺点确实是这在服务器上代表了可扩展性方面的成本; 以及在电池使用方面的客户成本。

在服务器上:

  • 套接字是相对稀缺的资源
  • 如果客户端有一个开放的连接,就不可能移动客户端进行负载均衡(但是您是否真的能够移动客户端?这取决于层次的责任)

在客户端:

  • 维护networking连接是非常昂贵的。 1秒的networking≈5分钟的睡眠。
  • XMPP图书馆不一定能在Android上运行得很好 。 而且我不知道在android上支持WebSockets 。

简答号

我不会开始一个新的项目,或者build议开始一个新的项目(因为你提到重新开始)需要一个依赖于HTTP的实时双向通信 – 作为无状态协议。 你可能会感到安慰,连接保持活着,但没有保证。

您的+ HTTP endpoint is easy to scale horizontally on server side当HTTP被用作请求和响应样式并且被认为是无状态时,pro是一个在上下文中的专家。 当你固有地需要保持连接活着时,它变得有点没有意义(尽pipe不是完全)。

HTTP确实提供了另外一个你在这里没有提到的好处。

  • 当其他端口可能被阻塞时,HTTP很容易处理企业防火墙代理。

正如其他人所说的那样,WebSockets或HTTP上的XMPP会有更好的成功率。

这取决于。 你认为你的应用程序是“实时聊天”吗? 你需要一个在场指示器,或者input指示器吗? 诸如那些需要连续连接的特征。 但是还有一组聊天应用程序可以描述为启用“应用程序内消息”。 这些应用程序在某些后端存储会话和会话列表; 只需在其他设备上安装应用程序并login,即可在此类应用程序中看到您的对话。 这些应用程序没有任何存在指示器或活跃感。

尽pipe我没有使用XMPP实现任何应用程序,但就消息持久性而言,使用XMPP(开箱即用)的最持久性是持续直到交付的,类似于SMS。 也许你可以build立一个XMPP存储/恢复机制,通过捕获经过的节,并将它们存储在你自己的数据库中。 但是,如果您不需要完整的“聊天”体验,那么使用数据库,HTTP服务和推送通知(以通知更新的线程)似乎是具有消息传递function的应用程序的坚实途径 – 我打算在iOS&我自己的Android应用程序现在。

让我知道如果你已经find了这个好的开源模式/ APIdevise。