How Does Designing And Implementing Streaming APIs Differ From RESTful API?

March 7, 2018
One question we get a lot from our potential customers, is how does designing and implementing streaming APIs differ from delivering a RESTful API? While there are many different types of streaming APIs, which could dramatically shift the design patterns you employ, when it comes to Streamdata.io, and using Server-Sent Events (SSE) in conjunction with JSON Patch, you won't have to shift your design patterns, it will just be a new way to think about how you deliver data. Minimizing how much shifting you will have to do, to be able to see an entirely new set of benefits for how you can do business using APIs.

 

"Delivering real time APIs using Streamdata.io
should have no effect on how you deliver APIs"


Server-Sent Events (SSE) uses HTTP as a transport just like your RESTful API does. You do not have to make any changes to how your API works to begin streaming using SSE. The only requirement is your API must provide JSON responses, in order to be able to apply JSON Patch. Which shouldn't be a problem for most APIs out there today.This is what makes Streamdata.io so valuable, is that if you are already providing a JSON API, you don't have to do anything different to turn on streaming. All you have to do is proxy your API with Streamdata.io, and it will begin streaming updates--something that takes a couple minutes of your time to setup via the Streamdata.io dashboard.

streaming APIsWhen it comes to consuming your streaming API, the only change will be that your HTTP request is now long running, and each update will come through as a JSON Patch, augmenting the initial JSON response received with each change. While it does take some change in your client code to handle the longer running HTTP request, and deal with the incremental updates, you shouldn't have to change your clients behavior too radically. However, depending on the type of data you are now streaming, it may have a profound effect on your user interface, requiring you too overhaul how you display data, content, and change with each incremental update that comes in via your new data streams.

Delivering real time streaming APIs using Streamdata.io should have no effect on how you deliver APIs, if you are already providing JSON APIs. Where it will start forcing a shift in behavior is at the client level. Your clients will still be using HTTP as a transport, but streaming forces us to think differently about how we publish data and content in the client user interface. Pushing you to consider how real time your data and content is, and define more meaningful ways in which we can be presented to your human consumers. The impact that designing and implementing streaming APIs using Streamdata.io will have on your existing API deliver processes will be next to none, but the impact it can have on how your clients consume and interact with your data and content will be significant.

There are 0 comments.

Have something to say?

Drop a comment below.

Share - 'How Does Designing And Implementing Streaming APIs Differ From RESTful API?' on Google Share - 'How Does Designing And Implementing Streaming APIs Differ From RESTful API?' on Facebook Share - 'How Does Designing And Implementing Streaming APIs Differ From RESTful API?' on Twitter Share - 'How Does Designing And Implementing Streaming APIs Differ From RESTful API?' on Reddit Share - 'How Does Designing And Implementing Streaming APIs Differ From RESTful API?' on LinkedIn