Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Put the Web in Web API

Learning Objectives

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.

Networkable APIs Are Game-Changers

APIs aren’t limited to what can be found in the same local network. Developers and citizen integrators can also consume APIs offered by remote systems and devices. These 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 keys to this expansive network are the API endpoints.

Note

Think of endpoints like electrical sockets that consuming applications plug into.

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, especially for Integration Trailblazers who look at the many APIs that are available to them as though they are just third party parts with which to construct new business outcomes and customer experiences.

API Economy

Depending on the volume of calls or some other way of breaking down different tiers of service, 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 a similar service. Google Maps, for example, has several well-known competitors, including Here.com.

A graph showing the growth of the ProgrammableWeb API directory since 2006. The graph shows a surge in APIs created between December 2010 and December 2020.

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 and citizen integrators. 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. The more composable the final solution is, the more flexible it is to take on new features from other APIs that raise the bar in terms of overall business capability.

API Growth Then and Now

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 requests 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 already baked into the web’s protocol (HTTP) through usage of special verbs like GET, PUT, and POST. Yes, it’s the same web protocol that you use everyday to visit your favorite websites.

The (Possible) Future of Integration

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 labyrinths 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. Using HTTP/2, gRPC can 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.

Same Idea, Different Tech

Whether it’s the web’s protocol, GraphQL, gRPC or some yet-to-be invented approach to APIs, in the end, the idea of networkable APIs is really about turning a business capability into a networkable service that other applications can remotely treat as an outsourced part of their customer experience. As the inventory of outsourceable parts (the API economy) grows, so too does your opportunity to outmaneuver the competition with innovations and experiences that would be difficult to achieve with everything done in-house.

The opportunity works in the other direction as well. What business competencies should your organization deliver to itself and external developers as a networkable service in the form of an API? It’s literally the multi-million dollar question, especially for those of you looking to become Integration Trailblazers!

Share your Trailhead feedback over on Salesforce Help.

We'd love to hear about your experience with Trailhead - you can now access the new feedback form anytime from the Salesforce Help site.

Learn More Continue to Share Feedback