REST APIs have become the dominant means for distributed applications to communicate over the last ten or fifteen years, whether that is client-server such as mobile applications, web clients, or server-server between monoliths and microservices. However, the way REST works and increasing demands on how the REST paradigm works has seen the idea and frameworks around REST-based web services evolve, including the adoption of the idea of streaming. Streaming represents the data source's ability to continuously send to the client data, just as we do with video and audio media, rather than request-reply. We will look at why we should consider it as part of our kit bag of technical options, how streaming works, the considerations needed in adopting the approach, and the frameworks that have supported and helped its adoption.

A closer look at the problem

Part of the success of REST comes from the fact that it elegantly uses the HTTP framework, making it easy to understand and work with. The first challenge is that when HTTP was designed, the world of the internet was largely a world of static or data that was changing slowly. Things have moved on, and we expect data to change constantly now and at greater and greater speeds. The first example of constant change is the sending of video and audio media, particularly when the video is of a live event. So there is no way of even considering pushing all the media to us before we consume it, although such an approach historically will have taken hours or days. As a result, a low-level connection is established between the client and server, allowing the server to have a steady series of data blocks — or a stream of data. Hence the term streaming. While they have grown, the sources of video and audio aren't so significant that we can't lean on a few providers to support us, and we plug in their services to our solutions. How many websites actually stream their own videos compared to integrating YouTube or Vimeo into their pages?

The problem is that the number of use cases that now need or expect a constant flow of data, sometimes flowing in both directions, has grown massively and extends into the world of more conventional text-based payloads. While in low-volume use cases, we can address the problem much like hitting refresh on the browser — in other words, we simply repeat the API request to the data source, which is what polling is. As you scale this up, it becomes a large consumption of resources — particularly if your refresh requests often result in no data changes. Even with network caches taking some of the burden, that's network traffic and caching servers that still need to be paid for. Not to mention the user experience, where the user can observe lag or latency because of the additional time from round-tripping the data again. There is also the overhead that every request goes through a handshake and authentication processes before we get to the logic of processing the actual request.

As backends to applications become a composition of microservices, if they are all polling each other, we will see an accumulation of latency and polling overhead. Again this presents a compute overhead, which in low-volume cases can be tolerated and addressed by increasing the amount of physical resources. When scaled up, it becomes a significant cost in terms of needing more network capacity, more servers, power, cooling, and so on. As a result, changes to improve execution cost, let alone the benefits of better user experience, make it worthwhile looking to invest engineering effort in creating the means for data to be streamed at least in one direction between client and server, if not both.

Security considerations

By allowing a stream of data to leave our servers, we do raise some security considerations. Can we be sure that the recipient of our stream is legitimate and the intended destination? Is it possible for a malicious actor to initiate or become the stream recipient (e.g., a man in the middle, compromised client, malicious request, etc.)? Can we be duped into putting into the stream more data than should be shared due to some sort of injection attack? Can we link the steady flow of data back to the request for audit purposes?

Conversely, if the client suddenly receives a connection and data pours down the connection, do we know who the data is from? Is someone spoofing a server? Can we trust the origin — after all, when a ...