14.3 API's
So far, this module only skimmed the surface of how web servers and applications process and exchange data. This checkpoint will introduce you to a key concept: application programming interface.
Over recent years, APIs have become increasingly more popular in software development, and every product manager is likely to, at some point in their career, come across the question "Can you use an API for that?" To better answer that question and understand the context in which it is asked, it's helpful to know a little about what APIs are and how they function.
By the end of this checkpoint, you should be able to do the following:
- Explain what APIs are and how they are used
What are APIs?
An application programming interface, or API, is the architectural component that allows data to be sent, retrieved, and processed between applications—be it on the same device or across the internet. This is similar to the request/response cycle you are familiar with from the previous checkpoints; the only difference is that instead of sending the web server a request for HTML code (which results in displaying a web page), the request is for data.
APIs are also specialized, which allows applications to understand a lot about what the other party is requesting. The API being used for the request can reveal quite a bit about the request itself. In short, APIs exchange data in a specified format that is recognized by both the client (the sender) and the server (the receiver).
Revisiting the postal services analogy used before, this is similar to the rules covering how you send and receive mail: writing the recipient's address in a particular location on the envelope, attaching an appropriate number of stamps, dropping the letter into a particular box where it will be collected, etc. Following these rules allows the postal service to easily process requests to send mail. Imagine how difficult that service would be to provide if every envelope was filled out in a different format, stamps didn't exist, and mail could be left for pickup anywhere and everywhere!
In the digital mail equivalent of online data exchange, APIs are sets of rules that software developers can follow to have their programs send data easily, with few additional instructions. When a client (sender) sends data in a specified format using a specific API, the server (recipient) can quickly and easily determine what the client is requesting.
Consider Dropbox, for example. Dropbox provides an API that allows a developer to list all the files in a directory by making a specifically formatted HTTP request. There are similar APIs for uploading, downloading, and deleting files—along with APIs to complete many other tasks. As long as the request is sent in the specified format, the API will return the list of all the files in the directory. In other words, an API is a great shortcut to achieving specific tasks. This capability also allows developers to request from the same API, regardless of whether the returned data will be used in a mobile app, web app, or desktop app.
The Dropbox APIs are used both for internal development at Dropbox and by developers outside Dropbox. If the requester has been approved to use an API—or the API is publicly available—any request that complies with the specified format will return the expected data.
Once you're working as a PM, you'll most likely work with HTTP APIs. You can take a closer look at an example of this type of API documentation from Dropbox. This specific API is for creating a new file in Dropbox:
It might look a little difficult to decipher, but rest assured, your developers can easily read it.
There are a few important parts that you can scan to get an idea about what this does:
- Description: A brief description about what this API call does
- Parameters: What the API needs to know in order to execute the request
- Returns: What the API provides back if you provide the right info
- Errors: Messages that you might receive if there's a problem with the API call
APIs are used to exchange data between programs or within a single application. They're often used to allow a product to make data available to other products by making calls across the internet. For instance, you could build a camera app for your iPhone that allows users to store photos on Dropbox. In this case, the camera app would use Dropbox APIs to let users log in and upload new photos to their Dropbox storage. These APIs work over the internet via HTTP.
APIs also provide access to already-built functions, which can be found in so-called API libraries. These resources allow developers to simplify development while also incorporating more complex functionality. So, what does this look like? Well, as you already know from a previous checkpoint, operating systems allow applications to interact with computer hardware without each program needing to recognize the peripherals (such as a specific type of mouse or monitor). But how is this accomplished? Through APIs—yes, APIs can be made across the internet, or they can be provided by software, like the APIs in operating systems. For example, your iPhone camera app relies on APIs so it can work with all iPhone cameras; you don't have to modify your application to handle each camera in each device individually.
So, what does an API developer do? If your team is building an application, the API developer's job is to program requests in the correct format. The developer also programs what the application does when it receives the response in the format the API provides.
These are complicated ideas, and they may be difficult to understand at first. But abstract design actually makes building software and applications a simpler, more straightforward process. Instead of having to develop every aspect of data exchange from scratch, developers can focus on assembling or accessing existing programs via APIs. They only need to create new code for the aspects that are unique to their program—code that determines specifically what the program does with the data it receives. With APIs, an application is able to outsource much of the processing to other programs designed for specific tasks.
API products
APIs are often made available to developers and products outside an organization. These APIs can be essential to platform strategies, especially when a product is the main platform for other products to offer add-on functionalities. For instance, Spotify makes their API available to developers and even features some of the apps developed on top of it on their website.
Salesforce is one of the best examples of this model. Their product offers a core infrastructure that other developers can customize and adapt—in other words, developers create specialized products that use the Salesforce APIs. The Salesforce AppExchange is one of the most robust marketplaces of third-party applications, and every application is built on top of Salesforce APIs. Salesforce users can then use these Salesforce apps to customize their use of the platform. This is a win-win for Salesforce and its users: users find Salesforce more valuable because they can modify the platform to meet their needs, and Salesforce cultivates users who are more deeply involved in the Salesforce ecosystem.
The video below provides insight into how to determine if developing an API is a good idea for your company. Check out this amazing video on API Economy by Witalij Rudnicki
Companies with a business model that encourages third-party applications to build on their platform will treat APIs as a product. They have product managers developing strategies and conducting market analysis to ensure that the APIs are an effective tool for expanding engagement with the company's core platform.
APIs also play a key role in interoperability. Interoperability is the ability of different systems and software to exchange and make use of information. One of the most common examples of interoperability—or lack thereof—is any app that works on Apple products but not on devices made by other manufacturers (or vice versa). In cases like these, the technology company avoided interoperability to protect their market.
Alternatively, the OAuth standard demonstrates the benefits of interoperability. OAuth (shortened from open authorization) is a publicly available (or open) standard for login access delegation. It allows the user to use the login security of one product, such as Facebook login credentials, to prove their identity and access another product—without sharing their password with the second product. When multiple products comply with the OAuth standard, other products can trust that the user has been verified by a secure login, even if it's not their product's login. Google also offers OAuth, as do Yahoo, Twitter, and many other companies. As you build a product, you may consider adding OAuth support, which gives access to those providers' login capabilities. It is more convenient for users, and it can save your product team considerable time they would otherwise have used building a unique login. Because OAuth does require that users have accounts on other services, Facebook is the most common OAuth option for consumer apps. Google is more common for B2B apps.
APIs can be open, like OAuth, which means that they're available for anyone to use. These often become standards and are widely adopted. APIs can also be closed, like Salesforce.
Anyone can build products that use closed APIs, but in these cases, the platform offering the APIs has control over access to the products. Only users of the core platform can access the features offered by the third-party applications. For instance, if you build an application using Salesforce's APIs, only users with Salesforce subscriptions will be able to use your application. Likewise, if your product is dependent on Facebook's OAuth for login, only Facebook users will be able to access your product.
If you are building a product that potentially could add user-accessible APIs, you'll need to consider how the addition of APIs would support your company goals and improve your users' experience. For companies like Dropbox, Twitter, and eBay, an API strategy added significant value, expanded their market footprint, and helped them acquire more users. And whether you build your own APIs or not, it is highly likely that you'll use them in developing products.
Checkout this video by the team at MuleSoft, which gives a nice overview of APIs: