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 to any socket and go.
APIs bring a similar level of predictability and reliability. They offer purpose-built connectivity that’s often in context. Integrating with them is easily repeatable and scalable. And, in many cases, they involve a reciprocal exchange of value. The fitness club owner gets power for her treadmills that she can rely on, and the service provider is able to measure and bill her for that consumption.
Benefits of Using APIs
APIs help open up a plethora of opportunities. Here are ways that software, customers, developers, and their teams can benefit from using APIs.
In the name of repeatability, 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, services, and customer experiences, 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 its mobile app. Mapping was never a part of the customer experience when it came to getting a taxi or limousine. But ride hailing services like Lyft saw an opportunity to improve the customer experience with maps.
Because of the API to Google Maps, Lyft didn’t have to worry about how to plug maps into its application. It's able to focus on the business processes that make for a great ride sharing experience.
The instincts to use APIs in this way, to build a great customer experience, should come naturally to those of you that aspire to be Integration Trailblazers. It will be up to you to teach others in your organization to think in this way.
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 opaque 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.
Increased Developer Productivity
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 applications, a reference to the API (more commonly referred to as "calling" an API) can supply the program with the expected data or functionality. 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.
When developers have this kind of productivity, the business gets unprecedented agility. As you learn in API-Led Integration for Business Reinvention, thanks to APIs, new products and better ways of doing business are achievable in a fraction of the time they used to be.
Using HTTP Protocols to Access Data
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 these connections available 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.
||Submit requested data to a server for processing
||Retrieve requested data from a server
||Update and replace existing data with new data being sent in the request
||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 from FitBit.
Notice that instead of the "www" you’re familiar with, FitBit uses "api". Here, developers can use the GET command to return the data needed to display in their applications. In the case of this endpoint, the expected response will include the last activity (running), as well as any fitness challenges the user recently completed.
If a connected treadmill were to use this API, it could 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 and, like a recipe that can include any ingredient, the only limitation in terms of what can be accomplished with a mashup is your imagination.
Thanks to the thousands of APIs that software developers can reach over the Internet (more than 23,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. It’s like a giant spice rack that’s available to you at any time. The sooner you start rethinking your organization’s business processes and customer experiences as mashups built from off-the-shelf ingredients, the sooner you’ll be on your way to using APIs to transform your business!