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 is the underlying communication protocol of 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)
  • 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 important information for you in the below article.


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 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 server, creating a lot of traffic (uses resources, but frees them as soon as 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
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 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
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

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 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
  • 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 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 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 — 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 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, these connection cannot continue from where it left.
  • Issue #3: Some browsers/intermediaries don’t support Server Push.


WebSockets allow both the server and the client to push messages at any time without any relation to a previous request. One notable advantage in 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 client and the response is processed by 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

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 behaviors 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 solves two different problems and cannot be compared with a simple perf test like this:

In first graph, REST overhead increases against number of messages because that many TCP connections need to be initiated and terminated and that many HTTP headers need to be sent and received. In the second graph, incremental cost of processing request/response for a REST endpoint is minimal and most of the time is spent in connection initiation/termination and honoring HTTP semantics. (Perf test and analysis from

However, you should now understand that websockets are a great choice for handling long-lived bidirectional data streaming in near real-time manner, whereas REST is great for occasional communications. Using websockets is a considerable investment, hence it is an overkill for occasional connections.

Webhooks (for communication between servers)

If you want to obtain data from your API on change of data, polling must be the first option that comes to your mind. But when it comes to communication between servers, inefficiencies in polling cost us a lot (on average, 98.5% of polls get wasted).

Webhooks — simple way for sending data between servers with no long-lived polling connections (Image from

Webhooks are the savior for this problem. Here remember that the communication generally happens between servers. First, the sender node registers a callback URL in the receiver node/s in advance. When an event occurs in the sender side, the webhook gets triggered and sends an event object with new data as a HTTP POST request to the receiver node/s using callback URLs registered in each of them.

The cool thing is, server load for both the sender and receiver nodes can be reduced drastically with webhooks. It ensures the better user experience while your developers can utilize your service endpoints for meaningful things without wasting for polling.

Webhooks are generally used for send notifications and state changes among servers when an event occurs. For an example, when a user unsubscribes via a button click in email, it gets to a server and the user unsubscribe event occurs, this event triggers the corresponding webhooks and they notify all the servers/services that the user has now unsubscribed from their service (Image from
  • Sample applications: Notifications when a new user registers or a current user updates an existing profile setting
  • Issue: Developers find it difficult to setup webhooks and scale HTTP services.

What to use for your next API?

Which technique to use depends on what makes more sense in the context of your application. Sure, you can use some tricks to simulate the behavior of one technology with the other, but it is usually preferable to use the one which fits your communication model better when used by-the-book.

✅ HTTP/1.1 vs HTTP/2: These are transport protocols. Mutiplexing capability in HTTP/2 is great, but not supported everywhere yet. In such cases, make sure falling back from HTTP/2 and HTTP/1.1 won’t create any mess in your application. For transferring data, HTTP/1.1 is still a great choice.

✅ RESTful APIs: So far, RESTful APIs are okay for web applications. But there are discussions happening on exploring better ways. An example is this concept — “Replace RESTful APIs with JSON-Pure”. I like the idea, in fact, JSON is developer-friendly and you can do wonders with it. But you know, these are developing concepts.

✅ JSON vs XML: Use JSON. It’s the trend, and so convenient to deal with too.

✅ HTTP Polling: This is old, but still a great choice for dealing with APIs. If your data is changing frequently or in real time, don’t use Short Polling, just use websockets, the better technology for real time. Always use Long and Periodic Polling appropriately (with REST principles).

✅ HTTP Streaming: This is good for applications like news/social media feeds, stock/score boards, tweets etc. But in practice, people use websockets than HTTP Streaming.

⚠️ HTTP/2 Server Push is great for sending resources to client in more managed way. But all intermediaries and browsers will not support this. Make sure you gracefully handle such fallbacks.

⚠️ Server-sent events are a rather new technology which isn’t yet supported by all major browsers, so it is not yet an option for a serious enterprise level web application (Yes, I agree that you can trick this technology to work).

✅ 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, collaboration tools, interactive experiences (inc. micro-interactions), and for cases where you need real-time updates in both directions.

✅ Webhooks are different from all above technologies because it solves a very specific problem. If your servers need to communicate frequently and/or bidirectionally, go for websockets. If your servers communicate occasionally, use REST calls. If your servers need to communicate unidirectionally on an event trigger, then go for webhooks. Don’t use polling to check changes in data or state, it’s a waste.

Any tips?

☝️ Proxies and intermediaries are crazy. They will eat up your packets or timeout unexpectedly. Be aware of that, and handle it gracefully.

☝️ Use secured transport protocols (HTTPS or WSS) to handle your communication. Then, intermediaries will have less impact on your connections. And it’s secure, you know.

☝️ Developers love webhooks. But make sure you apply it right.

☝️ You really need not to embrace the latest technology always, especially when you create enterprise level applications. Make sure all the infrastructure is supporting the technology you use. And if the infrastructure does not support your technology/architecture, make sure it falls back to a technology that just works everywhere and everything works gracefully with reduced capabilities.

Platform Engineer

Solving unanswered questions in high-scale web applications

Thilina Ashen Gamage

Written by

Software Engineer at Yaala Labs • Optimist & Product Person • Passionate about building things and learning how things work • Formerly MillenniumIT (LSEG Tech)

Platform Engineer

Solving unanswered questions in high-scale web applications

Thilina Ashen Gamage

Written by

Software Engineer at Yaala Labs • Optimist & Product Person • Passionate about building things and learning how things work • Formerly MillenniumIT (LSEG Tech)

Platform Engineer

Solving unanswered questions in high-scale web applications

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store