Building Your Own Data Platform with REST APIs
Watch this video to learn how using REST APIs alongside of an SDK can multiply the power of both.
An API is to software code what a UI is to users. It helps different bits of software interact with each other. And can help you turn a data application into a data platform. If you have access to them, you can do a lot with REST APIs that weren’t built into a particular SDK. For example, you could accept user inputs and pass them to the platform to be stored. Or acquire data and metadata from the application or from users. This can be very powerful when building portals.
I'm Ryan Haber. I work at Zoomdata with our APIs. I help document them, I help market and sell them, support them with customers, build samples with them. I like to think of myself as our API ambassador.
So, in my last video, I talked about using a software development kit to build your own application, and today, I'm gonna talk about using REST APIs alongside of the software development kit so you can multiply the power of either one. Now, if you don't know, an API is an application programming interface, and it is to software code what a UI is to users. The user interface helps users interact, and the API helps two different bits of software interact with each other.
Using Your Data Application as a Data Platform
So, where we're really headed when we're talking about using a software development kit and a REST API alongside of each other is we're talking about using your data application as a data platform. So, a good set of REST APIs makes this possible and makes it worthwhile. You can do a lot with REST APIs that maybe weren't built into the software development kit of your choice if you have access to them. You can do things like you can accept user inputs and then pass them along to the platform to be stored. You could take feedback from the platform and present it to the user.
An SDK might let you do some of that, as well. But, if you control the APIs, then you can intercept some of that traffic and modify it, you can pre-package it, you can parse and filter it before you pass it along. You can also do things like get data and metadata either from the application or from your user to allow them to exchange so that, if the user selects a new group by, then you can pass that along to the platform and vice-versa.
Use Case: Building a Portal for Customers
So, this all sounds very abstract, I know. So, what I'm gonna do is I'm gonna tell you a story. I've been working with a company called Acme Co, let's say, here at Zoomdata. Acme Co has a very particular challenge. Their challenge is that they're building a portal for their customers that they also want their own employees to be able to kind of build and rebuild on the fly for them so that their customer support success managers can build new dashboards for their customers on the fly and have those dashboards automatically be propagated to the customers. That's the problem. Another parameter for the problem is that the customers absolutely cannot see third party software. They need to see Acme Co's portal and that's it.
The Customer Facing Portal
So, here's what Acm eCo is doing with this combination of our software development kit and our REST APIs as well as their own developer skills. First, they have the portal designed - HTML, CSS, Java Script, the standard technologies. They're using Angular as their framework, but you could use whatever you wanted to. And then they use the software development kit to embed charts here, data here alongside their own functionality that we don't provide because it's not our business like accepting customer payments or shopping carts and so on. So, they've got all that built into their dashboard for their customers. It's beautiful. It looks very nice, does not look like any other software that you could buy off the shelf, which is what you want when you're offering a software.
The Customer Support Portal
On the other hand, though, this platform that they've used, Zoomdata, has a back end, which is really actually Zoomdata's front end that's being used by their customer support analysts. The customer support analysts build a dashboard upon customer request and store it in Zoomdata.
What’s Happening on the Back End
Now, when they go to log in, the customers go to log in, the dashboards that they're presented are gathered using API calls that get a list of all the dashboards and the specifications of the dashboards from Zoomdata's metadata and then use those to build those same dashboards in the customer's portal on the fly using Zoomdata charts. The charts populate the dashboards according to specifications, but this goes well beyond white labeling because they're actually rebuilding it. So, it's not just changing colors and border thicknesses. I don't think they actually even use borders. I think they just put the charts into the portal. It's really beautiful.
One Unique Product
And so, they have this fully featured integration where the back end is actually Zoomdata's front end, and that's managed like any other, although white labeled, so it still says Acme Co and uses Acme Co's colors so that the customer support people are working with Acme Co software, they think. But, for the paying customers who are paying a lot of money, they actually get a fully featured, fully integrated application that takes all of the software development kit and REST API functionality they've built and seamlessly integrates it with other functionality that they've bought from other vendors into one unique product for their own company.