HTTP and Websockets: Understanding the capabilities of today’s web communication technologies

Deciding what to choose for your next web API design

There are so many classifications for APIs. But when it comes to web communication, we can identify two significant API types — Web Service APIs (e.g. SOAP, JSON-RPC, XML-RPC, REST) and Websocket APIs. But, what do these really mean? Let’s dive into the world of web communication protocols and discuss how to choose the best API mechanisms at the end.

HTTP

HTTP is the underlying communication protocol of the World Wide Web. HTTP functions as a request-response protocol in the client-server computing model. HTTP/1.1 is the most common version of HTTP used in modern web browsers and servers. In comparison to early versions of HTTP, this version could implement critical performance optimizations and feature enhancements such as persistent and pipelined connections, chunked transfers, new header fields in request/response body etc. Among them, the following two headers are very notable, because most of the modern improvements to HTTP rely on these two headers.

Keep-Alive header to set policies for long-lived communications between hosts (timeout period and maximum request count to handle per connection)

header to set policies for long-lived communications between hosts (timeout period and maximum request count to handle per connection) Upgrade header to switch the connection to an enhanced protocol mode such as HTTP/2.0 ( h2 , h2c ) or Websockets ( websocket )

If you are interested in knowing what these really do, I have documented all the important information for you in the below article.

REST

The architectural style, REST (REpresentational State Transfer) is by far the most standardized way of structuring the web APIs for requests. REST is purely an architectural style based on several principles. The APIs adhering to REST principles are called RESTful APIs. REST APIs use a request/response model where every message from the server is the response to a message from the client. In general, RESTful APIs uses HTTP as its transport protocol. For such cases, lookups should use GET requests. PUT , POST , and DELETE requests should be used for mutation, creation, and deletion respectively (avoid using GET requests for updating information).

HTTP Polling

In HTTP Polling, the client polls the server requesting new information by adhering to one of the below mechanism. Polling is used by the vast majority of applications today and most of the times it goes with RESTful practices. In practice, HTTP Short Polling is very rarely used and HTTP Long Polling or Periodic Polling is always the choice.

HTTP Short Polling: Simpler approach. A lot of requests are processed as they come to the server, creating a lot of traffic (uses resources, but frees them as soon as the response is sent back). Since each connection is only open for a short period of time, many connections can be time-multiplexed.

00:00:00 C-> Is the cake ready?

00:00:01 S-> No, wait.

00:00:01 C-> Is the cake ready?

00:00:02 S-> No, wait.

00:00:02 C-> Is the cake ready?

00:00:03 S-> Yeah. Have some lad.

00:00:03 C-> Is the other cake ready?

HTTP Long Polling: One request goes to server and client is waiting for the response to come. The server holds the request open until new data is available (it’s unresolved and resources are blocked). You are notified with no delay when the server event happens. More complex and more server resources used.

HTTP Long Polling — Response is held until server process data (Image from shyamapadabatabyal.wordpress.com)

12:00 00:00:00 C-> Is the cake ready?

12:00 00:00:03 S-> Yeah. Have some lad.

12:00 00:00:03 C-> Is the other cake ready?

HTTP Periodic Polling: There’s a predefined time gap between two requests. This is an improved/managed version of polling. You can reduce server consumption by increasing the time gap between two requests. But if you need to be notified with no delay when the server event happens, this is not a good option.

HTTP Periodic Polling — Request is sent every n seconds (Image from ibm.com)

00:00:00 C-> Is the cake ready?

00:00:01 S-> No, wait.

00:00:03 C-> Is the cake ready?

00:00:04 S-> Yeah. Have some lad.

00:00:06 C-> Is the other cake ready?

HTTP Streaming

HTTP Streaming — provides a long-lived connection for instant and continuous data push (Image from realtimeapi.io)

The client makes an HTTP request, and the server trickles out a response of indefinite length (it’s like polling infinitely).HTTP streaming is performant, easy to consume and can be an alternative to WebSockets.

Issue: Intermediaries can interrupt the connection (e.g. timeout, intermediaries serving other requests in a round-robin manner). In such cases, it cannot guarantee the complete realtimeness.

00:00:00 CLIENT-> I need cakes

00:00:01 SERVER-> Wait for a moment.

00:00:01 SERVER-> Cake-1 is in process.

00:00:02 SERVER-> Have cake-1.

00:00:02 SERVER-> Wait for cake-2.

00:00:03 SERVER-> Cake-2 is in process.

00:00:03 SERVER-> You must be enjoying cake-1.

00:00:04 SERVER-> Have cake-2.

00:00:04 SERVER-> Wait for cake-3.

00:00:05 CLIENT-> Enough, I'm full.

SSE (Server Sent Events / EventSource)

SSE — events can be broadcast to multiple clients (Image from javaee.ch)

SSE connections can only push data to the browser. (communication is carried out from server to browser only, browsers can only subscribe to data updates originated by the server, but cannot send any data to the server)

00:00:00 CLIENT-> I need cakes

00:00:02 SERVER-> Have cake-1.

00:00:04 SERVER-> Have cake-2.

00:00:05 CLIENT-> Enough, I'm full.

Sample applications: Twitter updates, stock quotes, cricket scores, notifications to browser

Issue #1: Some browsers don’t support SSE.

Issue #2: Maximum number of open connections is limited to 6 or 8 over HTTP/1.1 (based on the browser version). If you use HTTP/2, there won’t be an issue because one single TCP connection is enough for all requests (thanks to multiplexed support in HTTP/2).

HTTP/2 Server Push

A mechanism for a server to proactively push assets (stylesheets, scripts, media) to the client cache in advance

Sample applications: Social media feeds, single-page apps

HTTP/2 is an efficient transport layer based on multiplexed streams (Image from SessionStack.com) — According to IETF, a “stream” is an independent, bidirectional sequence of frames exchanged between the client and server within an HTTP/2 connection. One of its main characteristics is that a single HTTP/2 connection can contain multiple concurrently open streams, with either endpoint interleaving frames from multiple streams.

Issue #1: Intermediaries (proxies, routers, hosts) can choose not to properly push information to the client as intended by the origin server.

Issue #2: Connections aren’t kept open indefinitely. A connection can be closed anytime even when the content pushing process happens. Once closed and opened again, this connection cannot continue from where it left.

Issue #3: Some browsers/intermediaries don’t support Server Push.

WebSockets

WebSockets allow both the server and the client to push messages at any time without any relation to a previous request. One notable advantage of using WebSockets is, almost every browser support WebSockets.

WebSocket solves a few issues with HTTP:

Bi-directional protocol — either client/server can send a message to the other party (In HTTP, the request is always initiated by the client and the response is processed by the server — making HTTP a uni-directional protocol)

Full-duplex communication — client and server can talk to each other independently at the same time.

Single TCP connection — After upgrading the HTTP connection in the beginning, client and server communicate over that same TCP connection throughout the lifecycle of WebSocket connection.

00:00:00 CLIENT-> I need cakes

00:00:01 SERVER-> Wait for a moment.

00:00:01 CLIENT-> Okay, cool.

00:00:02 SERVER-> Have cake-1.

00:00:02 SERVER-> Wait for cake-2.

00:00:03 CLIENT-> What is this flavor?

00:00:03 SERVER-> Don't you like it?

00:00:04 SERVER-> Have cake-2.

00:00:04 CLIENT-> I like it.

00:00:05 CLIENT-> But this is enough.

Websocket connection (Image from PubNub.com)

Sample applications: IM/Chat apps, Games, Admin frontends

Although WebSockets are said to be supported every browser, there can be exceptions in intermediaries too:

Unexpected behaviours in intermediaries: If your WebSocket connections go through proxies/firewalls, you may have noticed that such connections fail all the times. Always use Secured Websockets (WSS) to drastically reduce such failures. This case is nicely explained here: How HTML5 Web Sockets Interact With Proxy Servers and here too: WebSockets, caution required!. So take the caution and get ready to handle them by using WSS and falling back to a supportive protocol.

Intermediaries that don’t support WebSockets: If for some reason the WebSocket protocol is unavailable, make sure your connection automatically fallback to a suitable long-polling option.

REST vs Websockets — Perf Test

If you do a performance test for REST and Websockets, you may find that Websockets do better when high loads are present. This does not necessarily mean that REST is inefficient. My personal opinion is, comparing REST with Websockets is like comparing apples to oranges. These two features solve two different problems and cannot be compared with a simple perf test like this: