Put the Web in Web API
After completing this unit, you’ll be able to:
- Explain two reasons why web applications are becoming more popular.
- State common uses of web APIs.
- Understand the API economy and why API growth has been significant.
APIs aren’t limited to what can be found in the same local network. Developers can also consume APIs offered by remote systems and devices. This can be private connections, like networks found in businesses with multiple locations and data centers, or it can be a public network like the Internet. The key to this expansive network are API endpoints.
The number and types of devices that can be plugged into electrical sockets are limited only by the imaginations of inventors and the capacity of the utility. In the same way, the number of applications that can take advantage of the data abstracted by an API’s endpoint is limited only by the imaginations of developers and the capacity of the API provider’s infrastructure.
Case in point: It wasn’t long after Google offered an API for Google Maps that thousands of third-party developers stepped forward with unique and innovative applications that consumed the API, incorporating Google’s mapping functionality directly into their apps. Think Yelp, Lyft, Tesla, and any other application that provides a map with the Google copyright in the corner.
It is for this reason that APIs are often referred to as an engine of innovation.
Depending on the volume of calls, a provider like Google might charge the application developer a fee for using the API. This gives rise to the idea of an API economy. Now, the application developer must weigh all the costs of using the API versus developing the functionality from scratch. Or, as is often the case in the API economy, the developer can seek out a more economical provider for similar service. Google Maps, for example, has several well-known competitors, including Here.com.
The API economy’s growth is driven by service providers that compete to address this thirst for greater developer productivity and common data. For each of the various types of functionality that can be invoked via API (such as credit card processing, mapping, navigation, and translation), there are often multiple API providers competing for the attention of application developers. In turn, as more features are supplied in the form of API-based services, the API economy is accelerating the trend toward a world of applications that are primarily composed of off-the-shelf APIs.
You may be thinking networkable APIs are the greatest thing since sliced bread. You also may be wondering, if they’re so great, why didn’t the tech industry come up with them earlier? As it turns out, it did.
Back in the days when Unix first came out, it was not uncommon for programmers to remotely invoke business logic from another machine across a network through a technology called RPC, or remote procedure call.
Are you ready for some serious acronym soup? Over time, RPC’s gave way to other forms of remote data and functionality request such as Network DDE (dynamic data exchange), CORBA (common object request broker architecture), electronic data interchange (EDI), and so forth. Eventually, something called XML-RPC (woo hoo! RPC again!) surfaced, which later evolved into what we now know as web services, based on XML and the simple object access protocol (SOAP).
Each time a new technology for remote access of data or functionality emerged, the industry thought utopia had finally been achieved. But then along came web APIs of the sort that are fashionable today; ones that, as mentioned earlier, rely on the functionality that’s baked into the web’s protocol (HTTP) through usage of special verbs like GET, PUT, and POST.
So if history is any kind of indicator, the way we integrate between systems may be due for a change. There are now two relatively new API-like technologies that part ways with the currently favored web approach. One comes from Facebook, called GraphQL, and the other is from Google, called gRPC.
Both have their own advantages over current web APIs. For example, GraphQL is inspired by the idea of a social graph and how different data items like friends, photos, places of work, and so on, form labyrinth of interrelated information. GraphQL makes it possible to request information from across an entire graph of data at once (versus the multiple round-trips of requests it takes traditional APIs to accomplish the same thing).
gRPC on the other hand has its own advantages. It relies on HTTP/2 (HTTP version 2) which can stream data bidirectionally. gRPC can also turn an API into a streaming API that feeds its data to the consuming application as soon as that data becomes available. For certain real-time applications like a stock market ticker, that’s a much more efficient way of getting data as opposed to forcing the app to constantly check if there’s new data available like traditional APIs do.
In the end, the idea of web APIs is really about turning a business capability into a networkable service that other applications can remotely use. How those applications call those APIs is something that has changed more times than we can count over the years, and judging by the direction of things, it will continue to evolve even as we publish this to Trailhead!