HTTP and Websockets

A quick epilogue to the service/topic story: what approach is used in HTTP (and many other Internet protocols)? Of course, it's a classical request/reply architecture, and that is too bad!

HTTP has become one of the most prevalent protocols, but it does not provide a way to initiate communication from the server. Back when browsers displayed static web pages, that was fine, but now the content that is served to browsers is highly dynamic. And browsers, for security reasons, can't just use any protocol. For a long time, HTTP was the only option.

An initial "fix" to this was HTTP long polling: the client would issue an HTTP request, but instead of responding immediately the server would wait for some event to occur. Once the client got a response, he would immediately make another request, which would then block again. That's not what HTTP was supposed to do, but it works.

Fortunately, we recently got WebSockets, which handle bidirectional communication in a clean manner. Now, we basically have this:

Browser   Webserver
   ---- http ---->    Browser sends requests, server replies
   <- websocket ->    Browser and server can both send messages at any time

And ta-da! Universality was restored!