APIs for Modern Commerce

Chapter 1. The API Economy

The world can be seen as only connections, nothing else. We think of a dictionary as the repository of meaning, but it defines words only in terms of other words. I liked the idea that a piece of information is really defined only by what it’s related to, and how it’s related. There really is little else to meaning. The structure is everything. There are billions of neurons in our brains, but what are neurons? Just cells. The brain has no knowledge until connections are made between neurons. All that we know, all that we are, comes from the way our neurons are connected.

Tim Berners-Lee, Weaving the Web (Harper Business)

APIs facilitate today’s digital revolution, similar to how steam-powered engines enabled the Industrial Revolution in the 1700s. When you withdraw money from an ATM, check the weather, or buy a new pair of shoes, you’re using hundreds of APIs behind the scenes.

APIs are transformational because they allow for an organization’s functionality and data to be exposed to third parties. When those third parties discover and consume that functionality and data, they often add more value than the sum of the APIs they consume. APIs democratize access to functionality and data, similar to and building on many principles of the World Wide Web.

Note

Metcalfe’s law says that the value of a network is proportional to the square of the number of its users. The classic application of this law is to fax machines. A single fax machine in a network offers no value, but two fax machines facilitate communication between two individuals, three fax machines facilitate communication between nine individuals, and so on.

Metcafe’s law can also be applied to APIs over the internet. Individuals building world-changing applications can do so faster and with less cost than ever before because of the availability of these fundamental building blocks. When Facebook acquired WhatsApp for $18 billion, WhatsApp only had 55 employees. Instagram only had 13 employees when it was acquired for $1 billion.

Modern businesses are able to build upon an enormous network of functionality and data that is often exposed over APIs. In the past, businesses of all sizes had to have enormous staffs of people to do what can now be done using an API for a few pennies per million calls. It’s this compounding of innovations that adds exponential value to our economy.

APIs are especially important to commerce. Consumers of all types expect to shop where, when, and how they want, across any device. Every day, a new device that’s capable of facilitating a commerce transaction enters the market, whether it’s a dishwasher that’s capable of ordering its own detergent or a wearable fitness tracker that reorders your favorite pair of running shoes when they’re worn out. What underpins all these devices is their ability to consume commerce functionality and data over an API.

Before we get too far, let’s look at what an API actually is.

What Is an API?

API is an acronym for application programming interface. An API is simply an interface on top of an application or library that allows callers to execute functionality (e.g., calculate sales tax, query inventory, and add to shopping cart) or create/read/update/delete data (products, orders, prices, etc.). Think of it as a contract between a provider and a consumer.

Note

APIs have been with us since the beginning of software. This book on web APIs, where the caller of the API is decoupled from the producer and the transaction often occurs over a network boundary like the internet.

An API is conceptually similar to a legal contract, where two parties outline obligations to each other without going into too much detail about the implementation. For example, a contract between a steel manufacturer and a buyer calls for 100 tons of SAE grade 304L to be delivered in 60 days but doesn’t specify which mine the iron must be extracted from or what temperature the furnace must be set to. So long as it’s SAE grade 304L steel and it’s delivered within 60 days, the obligations of the contract are met.

It’s the exact same with APIs: specify the what but not the how. Providers of functionality or data document what they’re offering in great detail but do not describe how the functionality or data they’re exposing is produced. Additionally, the provider can offer promises pertaining to the uptime of the API, as well as response times, authentication and authorization schemes, pricing (often a charge per x number of API calls), and limits on how often the API can be called. If the consumer agrees to the terms offered by the producer and has the proper permissions from the provider, they’re free to call the API.

Without an API, you’d be left to directly query databases and perform other tricks that expose the caller to too many of the implementation details of the application you’re calling. An API abstracts away all of those details.

Note

Because there’s often ambiguity, it’s important to differentiate between APIs and microservices. Think of microservices as relating to how the application is built below the API. Microservices are individual pieces of business functionality that are independently developed, deployed, and managed by a small team of people from different disciplines. Microservices always expose functionality and data through APIs. APIs are always required for microservices, but microservices are not required for APIs.

APIs can be bolted on top of any application, whether on the microservice or monolithic end of the spectrum. For more about microservices, have a look at Microservices for Modern Commerce, by Kelly Goetsch (O’Reilly).

We’ll discuss this further in Chapter 3.

Now that we’ve defined APIs, let’s talk about why they are so relevant to commerce today.

Digitizing the World

With software powering the digital revolution we’re living through, APIs have emerged as the foundational currency. APIs are great for many different constituencies.

For end consumers, APIs allow for functionality and data to be consumed from any device, anywhere. Gone are the days when the only way to interact with an organization was through a browser-based website on a desktop. Consumers are now fully immersed in mobile devices, tablets, voice, wearables, and even “smart” devices like internet-connected refrigerators. They’re accessing functionality and data through third parties like social media and messaging platforms, native apps accessed through proprietary app stores, and native clients like those found in cars and appliances.

For organizations building consumer-facing experiences, it’s easier to consume functionality and data as a service over an API rather than downloading, installing, configuring, running, and maintaining large stacks of software and hardware. It makes a lot more sense to pay a vendor to run multitenant copies of the software for you at scale. You just get an API that you can code to, with the functionality delivered as a service. No need to install anything.

Software vendors like exposing their functionality and data as APIs because it allows outside developers to wire functionality and data into their applications in pieces. Rather than a large one-size-fits-all software package that must be entirely adopted and then customized, an API-based approach allows for developers to consume smaller, more granular pieces of functionality from specialized “best of breed” vendors. This strategy is how the public cloud vendors have changed the face of IT. As an example, have a look at the dozens of discrete services (all exposed as APIs) that you see when you log in to Amazon Web Services (Figure 1-1).

Figure 1-1. Amazon Web Services console

Some customers only use AWS for DNS. Some use it just for storage. It’s entirely up to the customer. This is increasingly how organizations and individual developers want to buy software. And it makes so much sense.

Perhaps the most important advantage of APIs is time to market for all parties involved, which is arguably the most important competitive differentiator in today’s digital revolution. Developers can simply consume little building blocks of functionality, similar to the Amazon Web Services model. Organizations don’t have to download, install, configure, run, or maintain anything. Software vendors can release new functionality to APIs many times a day, provided each API is backed by a separate microservice with its own team, application, infrastructure, and release cycle. Unless the change was big enough that it necessitated a breaking change to the API, the consumer of the API can start using the new functionality immediately without having to do anything.

APIs Are the Currency of Commerce

The fundamentals of retail (whether B2C or B2B) remain unchanged: get the right product to the right person at the right time for the right price. How this occurs in today’s technology-driven retail environment is completely different than ever before. For example, a 2016 study by Harvard Business School showed that 73% of consumers used multiple channels during their shopping journeys.

Technology and habits are quickly changing on the consumer side (the “C” in B2C), with the clear trend being toward mediation through consumer-focused platforms and electronics. This started with B2C commerce, but brands and B2B commerce are seeing these changes as well. Most consumers now engage with businesses through a handful of social media apps on consumer electronic devices, like smartphones. Even many of today’s B2B transactions are now occurring over mobile devices. With all this change on the consumer side, the notion of what constitutes a channel has fundamentally changed as well.

Defining a Channel

A channel used to be a discrete physical or virtual interaction with a customer, such as physical stores, websites, mobile applications, and kiosks. It was clear when your customer engaged with your brand. If your customer opened up your app on their smartphone, they were engaging with you directly through your mobile channel, with no other parties involved.

Things are different today. You now have to reach customers using dozens of smaller touchpoints. Social media (Instagram, Facebook, Pinterest, Twitter, Snapchat, YouTube, etc.), wearable devices, marketplaces (e.g., eBay, Amazon, and physical malls, which are beginning to have shoppable applications), smaller embedded “micro” applications on mobile devices (iMessage apps, etc.), and so on are now the primary means of interacting with retailers and brands. You have to be part of your customers’ everyday lives in order to remain relevant. You have to give them contextual content in the location of their choosing. Very few brands have enough value that a consumer will consume an entire channel, like a mobile application.

To further complicate matters, there’s a revolution in consumer electronics that’s allowing customers to interface with devices in ways that were previously never possible. Voice, for example, is rising in prominence. Apple’s Siri handles over two billion commands a week. An incredible 20% of Google searches on Android-powered handsets in the US are input by voice. Amazon Echo’ was one of 2016’s hottest holiday gifts. Commerce is now as simple as saying, “Alexa, buy me some AAA batteries.”

Beginning in 2007, consumer engagement started to be mediated by new gatekeepers. Prior to the iPhone being introduced in 2007, consumers more or less directly interfaced with your website. Perhaps as important as the iPhone itself was the concept of the app store, where customers could download trusted apps from a walled garden. By setting standards for, reviewing, and approving apps, Apple became a mediator between you and your customer. Android adopted the same model. Social media’s rise to prominence in 2010 brought even more mediation. In 2017, you have to reach customers where they are, on their own terms and through the platform of their choice. Experiences are now more and more mediated.

Mediated experiences require the use of APIs, which is why APIs are now the primary currency of commerce. Rather than build a single website or mobile app with its own stack, you should instead offer a suite of dozens, hundreds, or even thousands of discrete features as APIs. Some of those APIs can be built in-house, some can be outsourced to a partner, and some can be purchased from third parties. What matters is that the APIs are available and easily consumable from anywhere. Frontends can then consume those APIs to build compelling experiences for customers, without any synchronization required. Each piece of functionality (add to cart, claim coupon, etc.) or piece of data (product, category, customer, etc.) is accessed only through one API, rather than having to access multiple backend systems (ERP, CRM, OMS, etc.), as is often the case for enterprises.

For example, Best Buy is openly courting developers to integrate its APIs (Figure 1-2).

Figure 1-2. Best Buy’s public API catalog

Additionally, Amazon.com, Walmart, Tesco, eBay, Target, and most of the world’s other leading retailers are on board with offering functionality and data as APIs. Developers are then free to integrate the APIs wherever they see fit, often earning a commission on sales.

Jeff Bezos famously directed his staff at Amazon to adopt an API-first approach in a 2002 memo, which went something along these lines:

1. All teams will henceforth expose their data and functionality through service interfaces.

2. Teams must communicate with each other through these interfaces.

3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back doors whatsoever. The only communication allowed is via service interface calls over the network.

4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols—it doesn’t matter.

5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design so that interfaces that can be exposed to developers in the outside world. No exceptions.

Today, Amazon famously has thousands of APIs that it uses to “inject” Amazon.com into thousands of different social media and consumer electronics clients.

Gartner, the research and advisory company, states the following in its Hype Cycle for Digital Commerce, 2017 report:

API-based commerce will be critical for the future of commerce that comes to you, whereby commerce functions occur in the customer’s context wherever and using whatever channels are most convenient to them. Commerce journeys will become more fragmented and an API-based approach is a fundamental enabler for cross-channel experiences.

API-based commerce will need to be available as a set of discrete services that can be utilized independently (with an appropriate cost model), and these capabilities should no longer require a whole platform purchase or subscription.

Gartner, Hype Cycle for Digital Commerce 2017, Mike Lowndes, July 2017

Today’s commerce platforms are expected to be API-first because APIs are the only way of injecting commerce into mediated experiences. APIs are faster to integrate, offer more flexibility, and—if implemented using a microservices approach—support all of your future commerce initiatives.

Final Thoughts

Now that we’ve discussed APIs and how transformational they are, let’s look at how to model them.