Driving on 101 in San Francisco (the highway that runs between San Francisco and San Jose that connects most of what people know as “Silicon Valley”) you see a lot of different billboards for tech-related business solutions. One that stood out the first time I saw it was a sign that stated “Learn How to Use Your API Correctly,” and of course my first instinct was to search, “What is an API?” to answer the question for myself.
Things have come a long way since then, but in recent months here at Backblaze, it became clear that understanding exactly how APIs work was very important. And yet, on the verge of our biggest launch in years—our Backblaze S3 Compatible API—I realized that I was far from alone in not fully getting the functionality of APIs.
If you’re thinking about onboarding some new tools in your home or office that you hope will play well with your existing technology, understanding APIs can be hugely helpful. But when you search “What is an API” on Google, you get a lot of technical jargon that might be over your head at first glance.
To better understand what an API actually is, you need to break the definition into parts. We talked to some of our more patient engineers to make sure we understand exactly why developers and businesses are so excited about our new suite of Backblaze S3 Compatible APIs.
Defining an API (Definition #1)
The abbreviation, API, stands for application programming interface. But that doesn’t really answer the question. To get started more constructively, let’s break apart the abbreviation.
Defining “Application”
Application: An application is the software, website, iOS app, or almost any digital tool that you might want to use.
Defining “Programming”
Programming: This is what the developer—the person who built the digital tool you want to use—does. They program the software that you will be using, but they also program how that software can interact with other software. Without this layer of programming, those of us who aren’t developers would have a difficult time getting different applications to work together.
Defining an “Interface”
Interface: An interface is where applications or clearly defined layers of software talk to each other. In the cases we discuss here, we will focus on APIs that talk between applications. Just as a user interface makes it easier for the average person to interact with a website, APIs make it easier for developers to make different applications interact with one another.
Defining an API (Definition #2)
Okay, so now we know what makes up an API on a basic level. But really, what does it do?
Most simply, APIs are the directions for interaction between different types of software. A common metaphor for how an API works is the process of ordering dinner at a restaurant.
When you’re sitting at a table in a restaurant, you’re given a menu of choices to order from. The kitchen is part of the “system” and they will be the ones who prepare your order. But how will the kitchen know what you are picking from the menu? That’s where your waiter comes into play. In this example, the waiter is the communicator (the API) that takes what you chose from the menu and tells the kitchen what needs to be made. The waiter then takes what the kitchen makes for you and brings it back to your table for you to enjoy!
In this example, the kitchen is one application that makes things, the customer is an application that needs things, the menu is the list of API calls you can make, and the waiter is the programming interface that communicates the order of things back and forth between the two.
Types of APIs
With a working definition, it’s easier to understand how APIs work in practice. First, it’s important to understand the different types of APIs. Programmers choose from a variety of API types depending on the “order” you make off your “menu.” Some of these APIs have been created for public use and are widely and openly available to developers, some are for use between specific partners, and some of these APIs are proprietary, built specifically for one platform.
Public APIs
A public API is available to everyone for use (typically without having to pay any royalties to the original developer). There are no specific outlines to the way they are utilized, other than the intention that the API should be easily consumed by the average programmer and be accessible by as many different clients as possible. This helps software developers in that they don’t have to start from scratch every time they write a program—they can simply pull from public APIs.
For example, Amazon has released some public APIs that allow website developers to easily link to Amazon product information. These APIs communicate up-to-date prices so that individuals maintaining websites no longer need to update a link every time the price of a product they’ve listed changes.
Partner APIs
A partner API is publicly promoted but only shared with business partners who have signed an agreement with the API publisher. A common use case for partner APIs is a software integration between two businesses that have agreed to work together.
With our Backblaze B2 Cloud Storage product, we have many different integration partners that use partner APIs to better support customers’ unique use cases. A recent integration we have announced is with Flexify.IO. We work together using partner APIs to help customers migrate large amounts of data from one place to another (like from AWS to Backblaze B2 Cloud Storage).
Internal APIs
A private API is only for use by developers working within a single organization. The only exposure for this API is within the business and can be adjusted when needed to meet the needs of the company or their customers. When new applications are created they can be pushed out publicly for consumer use but the interface will not be visible to anyone outside of the organization.
We wish we could share an example, but that would mean the API would be public and no longer “internal.” A company like Facebook could provide a hypothetical example: Facebook owns WhatsApp, Instagram, and numerous other applications that they’ve worked to link together. It’s likely that these different applications speak to one another via internal APIs an open-source programmer might not have access to.
Defining Backblaze APIs
Typically, companies use a variety of public, partner, and internal APIs to provide products and services. This holds true with Backblaze, too. We use a balance of our own internal APIs and we also use some public-facing APIs.
In our data centers, our Backblaze Vault architecture combines 20 Storage Pods that work collectively to store customers’ files. When a customer uploads a file using the public B2 Native API call, we use our internal APIs to break the data into 20 pieces (we call them ”Shards”). The 20 Shards consist of 17 data Shards and three parity Shards which we spread out across all 20 Pods. Why? This is our way of keeping your data safe in the cloud. (You can read more about that process here.)
A common public API we have implemented is the Google Single Sign-on (SSO) authentification. SSO systems allow websites to use trusted sites to verify users. As a user, you would want to use SSO to add an extra layer of security onto your account. This public API allows users with Google Accounts to access their Backblaze account with their Google credentials.
At Backblaze, our engineering team has also created some public APIs with our product, B2 Cloud Storage, that are available for anyone interested in using our cloud storage product as part of their workflow. If you have ever uploaded data using Backblaze B2, then you have used our B2 Native API. Backblaze supports two different suites of APIs: the B2 Native API and, more recently, the Backblaze S3 Compatible API.
What Makes for a Successful API?
According to one of our lead engineers, there is a list of criteria that make an API successful or desirable. These criteria include:
-
- 1. Ease of use for programmers
-
- 2. Functionality
-
- 3. Security
-
- 4. Performance
-
- 5. How widely it’s adopted/in use
-
- 6. Longevity (as in, how long will your application be able to use this API without any changes)
-
- 7. Financial cost to license or use
When designing a new API or choosing from an existing API, there are other elements that can come into play, but these are front of mind for our team.
The challenge is that oftentimes, they compete with one another. For example, PostScript has an excellent functionality and it’s widely adopted as a way to communicate with printers, but unlike some APIs, there is a high licensing cost that must be paid to Adobe (who invented the PostScript API).
There are lots of trade offs to consider when developing APIs, so it’s rare that you accomplish a clean sweep of a totally free, very fast, totally secure, easy-to-use API that also has a complete set of functionality with longevity. But that’s the ideal.
So What Does That Mean for You?
If you’ve read this far, then you’ve gained a sense for the basics of APIs. This may have even gotten you thinking about creating some APIs of your own. Either way, if you want to understand the different pieces of technology you use every day and how they communicate, APIs are the key.
The next time you’re looking into a new piece of technology that might make your work or home life easier, you’ll know to ask the question: What sort of APIs does this tool support? Will it work with my website/hardware/application? And if it works, will it work well and continue to be supported?
Do you have a unique way you explain how APIs work to your friends? Feel free to share those in the comments section below!
