How The Decoupled Nature of Web APIs Gives Organizations Incredible Flexibility (includes video)

As a part of ProgrammableWeb's ongoing series of on-demand re-broadcasts of presentations that are given at the monthly Washington, DC-Area API meetup (anyone can attend), this article offers a recording and full transcript of the APIs 101 presentation that I gave on Feb 4, 2019. It's the second of a long-running series of 101 classes that I'll be giving at the meetup. Following up to Part 1 where I introduced the idea of the API contract and how it decouples API consumers from API providers, in this part, I discuss the opportunties created by that Decoupling -- and more specifically, the opportunities for organizations that decide to digitally transform themselves and modernize their IT legacies through API-led connectivity.

The DC-Area API Meetup almost always takes place on the first Tuesday of every month. The attendees consist of API enthusiasts and practitioners from all around the federal government as well as businesses and organizations that are local to the DC Metro area. There is no charge to attend and attendees get free pizza and beer, compliments of the sponsors. The meetup is always looking for great speakers and sustaining sponsors. If you're interested in either opportunity, please contact David Berlind at If you're interested in attending, just visit the meetup page and RSVP one of the upcoming meetups. It's that simple. 

Here's the video of my presentation:

How The Decoupled Nature of Web APIs Gives You Incredible Flexibility

Editor's Note: This and other original video content (interviews, demos, etc.) from ProgrammableWeb can also be found on ProgrammableWeb's YouTube Channel.

Audio-Only Version

Editor's note: ProgrammableWeb has started a podcast called ProgrammableWeb's Developers Rock Podcast. To subscribe to the podcast with an iPhone, go to ProgrammableWeb's iTunes channel. To subscribe via Google Play Music, go to our Google Play Music channel. Or point your podcatcher to our SoundCloud RSS feed or tune into our station on SoundCloud.

Tune into the ProgrammableWeb Radio Podcast on Google Play Music  Tune into the ProgrammableWeb Radio Podcast on Apple iTunes  Tune into the ProgrammableWeb Radio Podcast on SoundCloud

Transcript of: How The Decoupled Nature of Web APIs Gives You Incredible Flexibility

David Berlind: APIs 101. I'm going to give the part two of the talk that I gave in December before the snow storm. So, here we go. Just a quick review, if you remember the last talk, I said APIs are basically an alternative to User Interface. They're essentially an interface. They're just for a different kind of user than a human user. If you're used to using a cell phone, and the interface is designed for humans, APIs is the same kind of interface. It's just designed for software and machines. That's a easy way to talk about APIs.

We talked about the contract and how APIs essentially represent an interface that separates the concerns of the consumer and the provider, so just like an electrical socket, just like LEGO. We talked about... Here's the electrical socket. We talked about how you have that electrical socket providing a 120 volts, and then things can plug into it on one side. Those are the consumers, and the providers are underneath. We'll come back to that slide. LEGO, of course, has a very specific contract so that all the blocks fit together. In intermodal shipping containers, they have these things called twistlocks on them so that the containers can easily snap to trains, trucks, boats, each other, and that involves a standard. These are all real-world metaphors for the API contract.

We talked a little bit about how this API, this idea of the API contract does this thing we call decoupling, which basically separates the concerns of the consumer, let's say an application, and the provider, which would be an API provider. In the early days there's, there's been a long arc of history in terms of separating these concerns.

In the early days we had a technology called RPC or Remote Procedure Call, but today, when we think of networkable APIs, we primarily think about these APIs that are on the web. They call them web APIs. In fact, I think the name of this meetup is officially the DC Web API User Group. APIs are very much tied to the web's protocol these days — most of the ones. There are some newer classes of APIs coming out; however, they're networkable and not necessarily so reliant on the web.

I want to come back to this slide because I said that this in this month's presentation, was going to talk about the benefits of the contract, the benefits to organizations. There are benefits on both sides of the contract. Remember, when we think about the wall socket, there's a certain pattern to the holes in the wall socket. There's a certain number of volts coming through it, certain number of amps coming through it. There's a whole specification there.

What that contract does, what that specification makes possible, is the fact that you could be the maker of a hairdryer, as long as you make your hairdryer in a way that is expecting that kind of a specification or contract, that kind of electricity, you as the hairdryer manufacturer don't have to worry about the power side of the equation anymore. You don't care where the power's coming from. You don't care if you're plugging it in in Boston or in Washington, D.C. or San Francisco. It should all just work.

You also don't care who's on the other side of that socket providing that electricity and how they're providing it. This is a separation of concern. The hairdryer is not concerned with the provider at all. The hairdryer, just if the provider provides electricity from coal, nuclear, wind, hydro, solar, it doesn't matter. There are certain benefits of this. If you are on the client side, of course, you just don't have to concern yourself anymore with how the power is delivered. You just have to make a plug and make sure that you have the proper transformers and other components inside your device to take the 120 volts running at, whatever, 15 amps and convert it to whatever it is the actual device needs.

How many people have taken the opportunity to look at the power brick that comes with whatever they buy? Does anybody look at that? A few hands go up. Actually, if you look really closely at it, it tells you what that power brick is doing to the power that's coming out of the wall. It tells you exactly what it's changing it to, like if it's going from AC to DC and how many volts it will provide to the actual device. That's how you know, by the way, if you need to replace that power brick. If you look at the old one, you can see, you can read it and say, "I need something that does exactly this." That by itself is a contract.

If you make hairdryers or computers, if you make electric vehicles, or if you make toaster ovens, whatever it is you make, you don't have to worry about it. This makes it a lot easier for people who make devices to innovate. They don't have to worry about the power side. It's very flexible. That's a huge benefit because in the very old days, imagine if you had to take a device off the shelf, the store, bring it home, and punch a hole in your wall, rip the wires out, strip the wires, and then alligator clip them together. That would not work out well.

The reason that companies can sell hairdryers and computers at scale that they do, one reason they can do that is because they don't have to worry about the power side of the equation. Now, the contract for electricity is different in some places. For example, the contract electricity here in North America is very different from the contract for electricity in Europe. The pattern of the holes in the socket may be very different.

In fact, across Europe and in Asia, you see completely different standards for that, but it's still a contract. On the provider side is where things get really interesting. I'm sure some of you are in the business of providing APIs. On the provider side, you have this ability to say, "Well, look, now that there's a contract, I get some flexibility here. I just have to deliver 120 volts of alternating current at 15 amps to the socket in the wall. That's all I have to do, and the consumers of that don't know or care how I'm doing that."

What that means is I have some options. If I'm on coal right now, and I don't want to pollute the air anymore, I can change to something more sustainable, like hydroelectric or wind or solar. That could be a big difference. Maybe a coal cost too much money to run a coal burning plant. Maybe it's a lot cheaper to run wind, so if I want to reduce my costs, I can make the substitution so long as nothing changes at the socket in the wall, so long as you are conforming to that contract. It's very, very similar to a legal contract. In a legal contract, when a big sports star... I'll use Tom Brady because I'm from new England. When a big sports star has a contract with his team, the New England Patriots, there's a contract there, and it specifies the performance of both parties in the contract. It says, "Here, you, the provider, will do this, and we, the consumer, will do this in exchange for that." As long as the provider here is conforming to the contract, the whole ecosystem kind of stays in balance, and things keep going as they want. The hairdryer won't know if the electricity provider decided to change how it is they produce that electricity.

This speaks to an incredible benefit of this contract and the idea of APIs. If we come back into the API world, get out of the real world with these metaphors that I've been using, these analogies, you can have a lot of different consumers of APIs and a lot of different providers APIs.

I got the consumers on the top like a mobile phone or a server or some other piece of software, and on the bottom you have other servers, and then these are often web servers when we're talking about web APIs. This gets to the language we like to talk about, which is you have clients. How many people have heard the term client server computing? Client server computing.

Okay, so wait a minute wait. Way the back there, I saw the first hand go up was, you. There you go. Okay. You get a mule. Thank you very much. All right. This is like client server computing. The clients, or the API consumers, those are the applications that you run on your smartphone or maybe run on a computer, and the servers are the providers, the API providers. You have an ecosystem of API consumers and API providers.

ProgrammableWeb for example, you remember, I spoke of the directory that we have, all of the APIs in there were put in there by the API providers that own those APIs. They are the providers on the providers side. Developers come. The developers who build these applications, they are the API consumers, the applications themselves.

What are the different types of consumers? Well, web applications. Today, when you go to a website more and more, the website is less of a kind of static web pages and more of an application, and they are invariably consuming APIs to put the data and other information that they want on the screen. When you use Google... How many people have used Google Maps on their desktop computer or their notebook? Some hands. Okay. Great.

Guess what? That web app is going through APIs, and in fact, in many cases, going through some of the same APIs that the mobile app goes through. That speaks to one of the benefits of having APIs is that you can have one API, and it can be reused across a variety of consumers. So, you develop this thing once, and then you start to get some scale. Web apps may consume APIs, desktop applications may consume some APIs. I don't mean like Chrome running on your desktop. I mean an actual application running on your desktop. I'm using fewer and fewer of those these days, but one application I use is called Evernote. Anybody familiar with? It's pretty cool app. It's runs on the Mac.

Anyway, that application that runs on the desktop actually interfaces with Evernote's API's online at Evernote's data center, wherever that may be, and so too do the mobile applications from Evernote and so too does the web application from Evernote, so you see you have the same API is being shared across three different consumer types.

Mobile applications, of... Oh, server applications. Server applications often talk to each other. We're going to hear from Matthew Reinbold at Capital One after I get done talking, and I can guarantee you that the APIs that Capital One has in its infrastructure, while many of them may be consumed at some point by the mobile applications Capital One puts out, I'm willing to bet that they have back office business processes that have one server application talking to another server application through APIs and getting their information. Is that a correct statement, Matthew? Yeah.

Matthew Reinbold: 95 to one.

David: 95 to one. There we go. Yeah. Again, reusing APIs across multiple consumer types. Mobile applications of course, and then you have devices like the Internet of Things. Right now, I'm working on a little experiment where... I play guitar as a hobby, and I'm working on an experiment where I use a Raspberry Pi, and I'm creating some APIs on it so that I can remotely control whether my guitar amplifier is running in the clean mode or the boost mode — This is the difference between like really clean sounding guitar tones and like crunchy hard rock dirty sound — from a mobile phone or from a web app. It's actually relatively easy to do, but you can imagine that if you can just somehow find a way to connect something like a Raspberry Pi to a guitar amplifier, and again, it's not too difficult,. and put some APIs on that, suddenly, you're creating a new thing that's on the so-called Internet of Things. Those could be consumers of APIs as well.

We have a lot of different types of consumers. The key here is, is that organizations start to experience a significant scale and cost savings when you're sharing one source of truth into a backend system. If all of these applications share the same APIs, you don't have to build custom integrations. I'm oversimplifying it because, in some cases, you have layers of APIs, and the underlying, the deepest layer, the system APIs are the ones that get reused the most. As you get closer to the application, you might have some more specialized ones, but the point is, is that that reuse is one of the major driving benefits of APIs and why so many large enterprises are modernizing their legacy infrastructure and moving to more of an API-led scenario.

Let's talk about the benefits of decoupling, and let's put this in real terms. I showed you that graphic before with the hairdryer and the Tesla and the computer on top and on the bottom different sources of power. Let's put this in terms of the clients and consumers. Let's say you are an organization, and you have a backend data system. Let's say you're an airline, and your backend data system, all of the stuff that controls the flight, schedules, and the bookings and all of that is on an IBM mainframe, which is, in fact, the case for many airlines.

Well, that IBM mainframe may be costing you millions of dollars to maintain because IBM charges very exorbitant rates for the licensing of its software, the maintenance of its hardware, and you might be looking at that and saying, "Well, yeah, we put an API around the mainframe so that these different consumers, whether it's a server, whether it's a web app, whether it's a mobile phone, an iPhone, or an Android phone or a computer, can talk to that application in the IBM mainframe. That's great. We put the API in there, but guess what? That mainframe is gosh darn expensive. We might be able to save some money because now that there's a contract between the consumers and the providers, maybe we move to or Linux, or maybe we will move to Amazon Web Services, and we rebuild the entire business system that's in the mainframe in the cloud instead where it's a lot cheaper so long as we continue to service that same contract."

It's just like switching from solar to wind because as long as the consumers don't know or care, they're still looking for that same contract at the plug in the wall, as long as these consumers are looking for that same API contract, the same specification of the bits that come through the pipe, they don't care. They don't care that they're getting it from a mainframe or they're getting it from Amazon Web Services. Doesn't matter.

What this does is it gives the organization the flexibility to say, "Well, you know what? That mainframe's costing us $10 million a year. We can do it on Amazon Web Services for $1 million a year. That's a savings of $9 million a year," and guess what? That hits the bottom line in a very positive way. It's very stockholder-friendly. It's very career-friendly when you start saving your organization that kind of money.

There are other benefits too. You're not just always going to make a substitution like that in order to save money. You may find out that the current provider of your systems, the underlying, whether it's Linux or IBM or whatever it may be, maybe they're not performing as well. Let's just look at the clouds that are out there today. For example, let's say you have your system, you've built your system on Amazon Web Services, but there's also a Microsoft Azure and Google Cloud Platform (GCP). You may find that one of those platforms doesn't go down as often as the other one of the other platforms. You may decide, "Wait a minute, we're going to move to the other platform because reliability is one of the most important aspects of what it is we do. We can't afford the system to go down," or maybe the security is better.

I'm not saying that one has better security and the other, but maybe you decided, because of some analysis you've done, that Google cloud platform has the best security, and therefore, "I need to get off of Amazon Web Services because I really need the very best there is in security," or maybe you go back to the Amazon and say, "Guess what? We're moving to Google Cloud Platform unless you do something about your security." I'll tell you what, if you have enough money that will wake Amazon up, and they'll do something about it.

But the point is, that this contract that's in the middle gives you that flexibility to make those decisions. You can start to make important business decisions, decisions about your security, decisions about your reliability, decisions about your costs that you couldn't so easily make before. We're not even into the technical mumbo jumbo of how APIs work. We're just talking about the business benefits of the API, and that's why for me and for a lot of people, it's really important that everybody in the organization understand the benefits of APIs, the power of the API to be able to enable these sorts of business decisions.

It's just like in the old days when people used to enter... come out of the college with some computer, like PC skills. If you had PC skills, you were like a rockstar. The future organization, everybody in the organization's going to have to know this stuff. This is going to be just like the PC skills that people had to have when you wanted to get a job back in the '90s. You're going to have these basic skills, have a basic understanding of the power of that contract and decoupling and how that can be such a game-changer for businesses.

Later in the series, we'll get into how... I mean, let's take Uber. Uber didn't invent anything. How many people use Uber? Oh, first hand, right there. You get a mule. Fast, like Uber. Mule. Uber really didn't invent anything. Uber's really a mashup. They use Stripe to do... They borrowed a —

Jennifer: Actually...

David: What?

Jennifer: ... they don't use Stripe.

David: They don't use Stripe. What do they use, Jennifer?

Jennifer: They built their own.

David: Yeah, I'm sure though when they first started—

Jennifer: No, Lyft did.

David: Okay, so Lyft is using Stripe. Thank you for correcting me. No, it's great. The point is, is that you can borrow functionality through APIs to build whatever it is you build. Lyft used Stripe. I don't know which one of them uses Google Maps to put the mapping up. One of them uses Twilio to handle the phone services and the texting back and forth. I mean, one of the things that most people don't know is when you call your driver, he doesn't see your number. If he calls you, he or she, you don't see their number either, and that's all done through a service like Twilio.

Three quarters of the functionality that these car sharing services are using aren't even functionality that they wrote. For you as a business person just in an organization to understand why it is that APIs enable that kind of innovation and that kind of flexibility like what I'm talking about here, those could be game changing things for businesses. Those can change customer experiences. Those can disrupt entire industries, and they are disrupting entire industries, and so it's helpful for everybody to have the basic understanding of why APIs are so incredibly powerful.

I don't want to really belabor... I'm trying to keep these kind of tight. We have many more parts of the series to go, so I'm going to end here on the benefits of decoupling. The next part of this series, I'm going to talk about how an API mindset forces change in organizational culture and how to think about how organizations not only should be organized, but more about what I was just talking about, how everybody in the organization really needs to have this kind of API mindset to help their organizations not only succeed in the future, but survive the disruption of other companies that want to take them out, the same way that Uber and Lyft have taken out taxi cab companies and limousine companies. So, with that, I want to say thank you.

Be sure to read the next API Education article: What is a gRPC API and How Does it Work?