Is it ok to use HTTP REST API for Chat application?

Question

We are building a chat application on Android. We are thinking of using HTTP REST API to send outbound messages. Wanted to know if it's a good approach or has any downsides compared to using WebSockets or XMPP (which seems to be more of a defacto standard for transferring chat messages)?

Some of the pros/cons I can think of are:

• HTTP endpoint is easy to scale horizontally on the server side (This is the main concern)
• Learning curve for Websockets is steeper compared to HTTP

• HTTP messages would have a larger payload compared to WebSockets

As per this document, it seems even Facebook used AJAX to handle chat messages initially:

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

Answer 1

We can use REST API for chat messaging, but IMHO, XMPP is a better alternative. Let's consider what XMPP has to offer.

XMPP beside supporting TCP transport also provides HTTP (via polling and binding) and websocket transports. Read XMPP via HTTP and WebSocket transports

It would be interesting to understand pros and cons of each transport from XMPP perspective.

XMPP could use HTTP in two ways: polling[18] and binding.

XMPP over HTTP Polling

The polling method, now deprecated, essentially implies messages stored on a server-side database are being fetched (and posted) regularly by an XMPP client by way of HTTP 'GET' and 'POST' requests.

---

XMPP over HTTP Binding (BOSH)

The binding method is considered more efficient than the regular HTTP 'GET' and 'POST' requests in Polling method because it reduces latency and bandwidth consumption over other HTTP polling techniques

However, this also poses a disadvantage that sockets remain open for an extended length of time, awaiting the client's next request

The binding method, implemented using Bidirectional-streams Over Synchronous HTTP (BOSH),[19] allows servers to push messages to clients as soon as they are sent. This push model of notification is more efficient than polling, where many of the polls return no new data.

It would be good if we understand how the BOSH technique works.

The technique employed by BOSH, which is sometimes called "HTTP long polling", reduces latency and bandwidth consumption over other HTTP polling techniques. When the client sends a request, the connection manager does not immediately send a response; instead it holds the request open until it has data to actually send to the client (or an agreed-to length of inactivity has elapsed). The client then immediately sends a new request to the connection manager, continuing the long polling loop.

If the connection manager does not have any data to send to the client after some agreed-to length of time [12], it sends a response with an empty . This serves a similar purpose to whitespace keep-alives or XMPP Ping (XEP-0199) [13]; it helps keep a socket connection active which prevents some intermediaries (firewalls, proxies, etc) from silently dropping it, and helps to detect breaks in a reasonable amount of time.

---

XMPP over WebSocket binding

XMPP supports WebSocket binding which is a more efficient transport

A perhaps more efficient transport for real-time messaging is WebSocket, a web technology providing for bi-directional, full-duplex communications channels over a single TCP connection. XMPP over WebSocket binding is defined in the IETF proposed standard RFC 7395.

Speaking of the learning curve, yes, you might be tempted to use the REST API, but now there are several resources to learn about Android and XMPP, and XMPP server softwares that you can use to run your own XMPP service, either over the Internet or on a local area network. It would be worth spending this effort before you decide your architecture.