The Key Differences Between Streaming APIs and REST APIs
Databases are where real-time data streams go to die. They are a dam in the stream, preventing vital, real-time information from getting to the people who need to make critical business decisions in latency-sensitive time windows.
The reason for this hold-up stems from wildly divergent time scales involved with information retrieval from different storage mediums and, more importantly, the mode with which the data is delivered to recipients.
Databases, by and large, write to disk, which has a relative access time of around 10ms, which, compared to in-memory access, is 40 times slower. The other compounding problem is that databases are designed to be queried, where data at rest is found by query resolution and put back into motion. Because only the database knows when any of its data has changed, all parties interested in detecting change across various pieces of data must continue to execute queries repeatedly, wasting database resources and their own.
Request-response APIs, based on the concept of “fetch,” are well-paired to the database query paradigm. Like a database query, these APIs entail locating data of interest, such as data that has been updated, and setting it back into motion. What if we could keep this streaming data in motion and avoid this impedance mismatch? Fortunately, this question has an answer: Streaming APIs.
The difference between Streaming APIs and REST APIs
If streaming data is a raging river, then Streaming APIs are the smaller, calmer capillaries that flow from it. They present specific information to you instead of sorting everything for small changes. No more torrents; just labeled, manageable streams. Streaming APIs are often overshadowed by their more popular request-response counterpart, REST APIs. REST APIs were designed for static content, like web pages, that don’t need to provide you with real-time information. These apps are stateless, making them less than ideal for contextualizing data.
Streaming APIs, on the other hand, contextualize the data relationship with the requesting client and are a natural fit for statefulness. While a REST API will query to learn if anything has changed, a Streaming API will function as a continuous query and return results just as they happen without having to be asked. Streaming APIs facilitate pushing data all the way through the application stack.
Despite the immense efficiency gains of Streaming APIs, many organizations still try to rely on REST APIs for real-time information, taking a “good enough” approach. As the volume of data streams increases, this becomes a less tenable position and a much costlier endeavor with all the wasted resources.
The benefits of using Streaming APIs with streaming data
When given the choice between Streaming APIs and REST APIs, many people might choose to go with the latter simply because they aren’t aware the former even exists.
If you have streaming data, but you’re not using Streaming APIs, you are setting yourself up for complex data challenges to solve going forward, including a much larger operational footprint. Streaming APIs provide organizations with:
- Decreased Latency - Removing polling and reducing access times by 40x means information can flow much more quickly.
- Efficiency - Streaming APIs are much more efficient than REST APIs, reducing the wasteful operational churn of unnecessary polling and unnecessary query compute.
- Scale - Streaming APIs may allow you to be more specific about the information you’re receiving because, unlike a REST API which fulfills one particular request for a given recipient, a Streaming API can update many recipients with a single update, as well as compose and re-use intermediate results.
How to get started with Streaming APIs
Swim is the first (and only) open-source, full-stack platform for building, managing, and operating streaming applications at scale. Interested in trying Swim out for yourself? Our code is open source. Check out one of our step-by-step tutorials.