Push over HTTP

is it really possible to push data using HTTP?

Photo by Tim Mossholder on Unsplash

There is a good requirement in the industry where you need to update data over the web in real-time. If you have worked in any real-time web application where data needs to be updated in UI in real-time like Trading platforms, Notification system, Reservation systems, Ticketing systems, etc. you would have been easily understood the requirement and power of PUSH.

Web Limitation: We majorly use HTTP/s as a communication protocol for web development and we know, it's unidirectional and stateless in nature. By Uni-directional we understand that data will flow in one-directional only i.e. only client can instantiate request for data and server can only send response against the same. It needs to be clear in mind that in HTTP protocol, the server can’t send any data without getting a request from the client which is actually a case of PUSH. So server can’t PUSH data over HTTP to the client if it's not requested.

Solutions: Now, how can we simulate PUSH in HTTP if Server can’t send the data without client order it, as we know necessity is the mother of all inventions, there are a couple of techniques by which you can achieve real-time push with some pros and cons.

1. Long polling
2. Server-Sent Events
3. Web Sockets

1. In LONG POLLING the normal HTTP request constructed using XHR is suspended at server-side and the server keeps it suspended until it has data to deliver to the client. Once the server is ready with data it responds to the client on the suspended request and closes the connection. The process is repeated when the client has to request for data.

Advantages: It’s easy to implement on the client-side with a good error-handling system and timeout management. This reliable technique also allows a round-trip between connections on the server-side, since connections are not persistent (a good thing, when you have a lot of clients on your application). It also works on all browsers; you only make use of the XMLHttpRequest object by issuing a simple Ajax request.

Disadvantage: There is no main disadvantage but this one still relies on a stateless HTTP connection, which requires special features on the server-side to be able to temporarily suspend it.

2. SERVER SENT EVENTS — Server-Sent Events (SSE) is a standard describing how servers can initiate data transmission towards clients once an initial client connection has been established. It is commonly used to send message updates or continuous data streams to a browser client and designed to enhance native, cross-browser streaming through a JavaScript API called EventSource, through which a client requests a particular URL in order to receive an event stream. When communicating using SSEs, a server can push data to your app whenever it wants, without the need to make an initial request. In other words, updates can be streamed from server to client as they happen. SSEs open a single unidirectional channel between server and client

• The main difference between Server-Sent Events and long-polling is that SSEs are handled directly by the browser and the user simply has to listen for messages.
• Server-Sent Events are based on HTTP streaming. As described above, the response stays open and event data are written as they occur on the server-side. Theoretically, HTTP streaming will cause trouble if network intermediaries such as HTTP proxies do not forward partial responses immediately. The current HTTP RFC (RFC 2616 Hypertext Transfer Protocol — HTTP/1.1) does not require that partial responses have to be forwarded immediately. However, a lot of popular, well-working web applications exists which are built on the HTTP Streaming approach. Furthermore, production-level intermediaries always avoid buffering large amounts of data to minimize their memory usage.
• In contrast to other popular Comet protocols such as Bayeux or BOSH, Server-Sent Events support a unidirectional server-to-client channel only. The Bayeux protocol on the other side supports a bidirectional communication channel. Furthermore, Bayeux can use HTTP streaming as well as long polling. Like Bayeux, the BOSH protocol is a bidirectional protocol. BOSH is based on the long polling approach.
• Although Server-Sent Events do have less functionality than Bayeux or BOSH, Server-Sent Events have the potential to become the dominant protocol for use cases where a unidirectional server push channel is required only (which is the case in many instances). The Sever-Sent Events protocol is much simpler than Bayeux or BOSH. For instance, you are able to test the event stream by using telnet. No handshake protocols have to be implemented. Just send the HTTP GET request and get the event stream. Furthermore, Server-Sent Events will be supported natively by all HTML5-compatible browsers. In contrast, Bayeux and BOSH protocol is implemented on the top of the browser language environment.

3.The WEBSOCKET specification defines an API establishing “socket” connections between a web browser and a server. In plain words: There is a persistent connection between the client and the server and both parties can start sending data at any time. WebSockets enables bi-directional, full-duplex communication channels, and many browsers (Firefox, Google Chrome, and Safari) already support it. The connection is opened through an HTTP request, called a WebSockets handshake, with some special headers. The connection is kept alive, and you can write and receive data in JavaScript as if you were using a raw TCP socket.

Advantages: WebSockets provides powerful, bi-directional, low-latency, and easy-to-handle errors. There isn’t a lot of connection, like Comet long polling, and it doesn’t have the drawbacks of Comet streaming. The API is also very easy to use directly without any additional layers, compared to Comet, which requires a good library to handle reconnection, timeout, Ajax requests, acknowledgments, and the optionally different transports (Ajax long polling and jsonp polling).

Disadvantages: No request scope. Since WebSockets is a TCP socket and not an HTTP request, request-scoped services, like Hibernate’s SessionInViewFilter, cannot be used easily

SERVER-SENT EVENTS VS. WEBSOCKETS

Why would you choose Server-Sent Events over WebSockets?

One reason SSEs have been kept in the shadow because later APIs like WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions. However, in some scenarios data doesn’t need to be sent from the client. You simply need updates from some server action. A few examples would be friends’ status updates, stock tickers, news feeds, or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexDB object store). If you’ll need to send data to a server,XMLHttpRequest is always a friend.

SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.

I hope I am clear in my thoughts here, based on above understanding one can decide the best push option for his application.