Learn the Benefits of APIs
After completing this unit, you’ll be able to:
- Define abstraction.
- Name the benefits of using an API.
- Explain HTTP verbs and their usage.
While setting up her fitness equipment, the fitness club owner begins to imagine what this process would be like without having standard specifications for electrical power. The equipment wouldn’t be the only thing to worry about. Things like the wiring in the walls, additional devices the wiring is shared with, how the electricity is generated (wind farm, nuclear plant, coal-fired generator, or solar panels), even where the source of power is located. Luckily, she doesn’t have to worry about the small details, just plug it in and go.
APIs bring a similar level of predictability and reliability.
APIs help open up a plethora of opportunities. Here are ways that software, customers, developers, and their teams can benefit from using APIs.
Any compatible device (in this case, the gym equipment) can easily outsource its electrical requirements to a service, and those devices can expect to get the same results. Similarly, APIs allow you to outsource key data and functionality through a predictable standard interface. Focus on making great applications and services, not on figuring out how you’re going to get common, yet nuanced information.
Consider how Lyft relies on the standard interface to Google Maps to import mapping and geolocation into their mobile app. They don’t have to worry about how to make maps work. They are able to focus on the business processes that make ride sharing successful and leave the details of mapping to the service provider, Google.
Consuming-devices are easily moved from one socket to another. For example, with no plug, matching socket or specifications, the gym owner may have to hardwire equipment into the walls of the building. This would involve gathering the required tools, exposing all the wires and joining them together. Of course, she would also need to know something about the wires coming out of the wall.
Thanks to a standard interface, moving equipment is simple. (Think about upgrading software, migrating to a new service, or expanding your data center footprint.) Even if the pattern of the interface changes—as it does when traveling from North America to the United Kingdom—consuming devices can be easily adapted as the standards are well-defined and documented.
When taking a look at the fitness club, the electrical socket is a layer of abstraction to the underlying service, or electricity. What is abstraction you ask? It is a way of hiding the working details of another system.
As long as the service delivers 120 volts of AC power to the wall socket in the standard way, the service provider is free to change anything and everything from just behind the socket all the way to the source of power. Any changes are transparent to consuming devices.
APIs serve as a layer of abstraction between the data or function being provided and the logic required to complete and run a task at the source. In other words, your software just needs to know how to connect to the other system, not how the other system works.
When programmers write code, they rarely start from scratch. APIs are designed to take an existing code base and use it whenever, wherever instead of attempting to re-create those features. While reusing existing code limits differentiation between developers, a reference to the API (more commonly referred to as calling an API) can supply it with the expected data. Given how APIs can handle common tasks, and can even handle not-so-common tasks, APIs can minimize application development time from months, or even years, to weeks.
While there are no rules or laws deciding exactly how developers must connect their applications to an API, several standards have emerged. For example, when applications connect to APIs from across the Internet, the majority of API providers make the connections over HTTP, or hypertext transfer protocol, otherwise known as the World Wide Web.
Whether it’s an application on your phone calling an API, or you’re retrieving your current calorie count through a web browser, or you are saving your workout information through the fitness equipment software, you’re relying on a special set of HTTP commands called verbs.
|POST||Submit requested data to a server for processing|
|GET||Retrieve requested data from a server|
|PUT||Update and replace existing data with new data being sent in the request|
|DELETE||Remove the requested data from the server|
In most cases, the service provider provisions a special web address known as an API endpoint for the software to connect to using an HTTP verb. Here’s an example of an endpoint from FitBit.
Notice that instead of the www you’re familiar with, FitBit uses api. Here, a developer can use the GET command to return the data needed to display. The expected response will include the last activity (running), as well as any fitness challenges that the user did previously.
If a connected treadmill were to use this API, it can show a wealth of information useful to the runner! Take this example of the response received after making a GET request to the Fitbit API.
Get this: Applications aren’t limited to using one API at a time! An application can make calls to multiple APIs and API providers. These composite applications are sometimes called mashups. Thanks to the thousands of APIs that software developers can reach over the Internet (more than 20,000 by last count according to ProgrammableWeb.com), the Web has turned into a programmable platform that’s equally, if not more, powerful than programmable platforms including Windows, Mac, and Linux.