What is an API?

Hi I’m Jared Hillam.

Let’s do a quick test. Take any one of your most used websites, amazon, twitter, ebay, youtube, snapchat, coinbase, opentable, whatever. And type its name into google then the acronym api. Every one of those websites is going to come up with a developer reference page. And you’ll find this not only for websites, but every major business application will have an API as well. So clearly API’s play an important role. But which exactly?

API stands for Application Programming Interface. The intent for APIs is to provide a way for developers to interact with each others applications. The reason the general public doesn’t usually know about APIs is because the public’s interface is driven by a Graphical User Interface, with log-in screens, and all the other widgets you’d normally see after logging into a site. But an Application Programming Interface represents its logins and other events in the form of published command-types which the publisher designs their application to understand. So instead of moving a mouse around and interacting with the application the API cuts through all that and allows for direct commands to be issued. 

There are literally millions of applications today that speak to each other through their APIs. Everything from automation scripts, event triggers, queries, and even full on assemblies for other Graphical User Interfaces use APIs.

APIs have been around for many decades, they came into existence well before graphical interfaces hit the market. But the kinds of APIs we have today called REST APIs are highly tuned for web based applications. For example, they follow a simple standard that is easy to understand.  They’re stateless, meaning they don’t exist until you call them, and they’re scalable to many little message transactions between machines over the web. And this makes them tolerant to the finicky nature of the internet which can easily drop a package of data. 

So REST APIs are basically the language of machines over the web, but here is where I ask you. How does REST work with large cloud data stores like Snowflake?

In a lot of ways the strengths of REST and the strengths of Snowflake are complete opposites. REST excels at tiny commands and data packages, Snowflake excels at large data requests. The best way to understand this is to go through a few real world examples. 

Imagine you wanted to kick off an aggregation query in Snowflake from your application, then have a resulting metric come back to your web app. With the REST API contacting Snowflake to kick off the command you get the nimbleness of REST coupled with the massive processing power of Snowflake. To the user it appears that a numeric value appears in seconds, but on the back end it could be that billions of records were aggregated.

or

Imagine you have a parameter you wanna pass from your app to control a Snowflake query. For example you might have an app that creates a specialized selection criteria, which if provided to Snowflake would define a very strategic slice of data. 

or

Imagine you want to execute administrative events inside of Snowflake like adding users or changing their roles. For example you might have an app that assigns role changes within access management systems. REST would provide a hook for making such changes within Snowflake.

or

Imagine you wanted to simply kick off a task within Snowflake which completes a chain of events that need to run on a monthly basis for your application to work. 

Intricity conducted a detailed walkthrough of Snowflake REST APIs during one of its Snowflake ProTalk events. The recording plus the code and the cheat sheets are on Intricity’s teachable site linked in the video description. Additionally, if you’re looking to build out your custom REST interchange with Snowflake I recommend you reach out to Intricity to talk with a specialist, you’ll find a link for that as well.