TechStuff Tidbits: The One About APIs

was a kid, hardly anyone even had a computer. If you did have a computer, you know, it was its own device. It was air gapped because there was no such thing as a public internet yet. I mean maybe if you were working with you know, arpinnet or something, you had a system that was connected, but most of us didn't. Also, when I was a kid, the movie ticket was four bucks and Disney World was just the

Magic Kingdom. Also had to walk to school and it was uphill both ways, and you know, you get the drift. But then things change, right, For instance, Disney went ahead and built three other theme parks at Disney World, and movie tickets got way more expensive, and we also started calling programs applications and something else would emerge that would change programming, the rise of the Application programming interface or API. So we're doing a tech stuff tidbits about what APIs

are and where they come from. Now. To be clear, the actual concept of the API is quite old. It comes from way before my time. So arguably you could say the earliest work that would evolve into what we would later be called an API actually started back in the nineteen forties. But the reason is because you had all these different teams around the world making computer systems. These systems were kind of you know, they were independent,

they weren't interoperable, they weren't compatible. So there were people who saw the need to create tools that would allow

for at least some interoperability. Otherwise you're really limiting innovation, right If you've got a brilliant programmer, a brilliant developer who has come up with this great idea for a computer program, but they're only familiar with one computer system, you've really limited the utility of that program, at least until someone who is familiar with a different computer system can come along and then perhaps port that program to

other systems. So there was the recognition of a need to create sort of a common ground that could work across different computer systems. The actual term for API, at least a version of this term, because back then it was called application program interface rather than programming, shows up in a paper that was titled Data Structures and Techniques

for Remote Computer Graphics. It was written by Ira W. Cotton and Frank S. Great Rex, which might be the best surname I've ever seen great Res Anyway, the paper describes the technology needed to allow for a quote, providing a remotely accessed interactive computer graphics system end quote. So not an API as we would understand it today, at least not the kind of API we typically talk about when you see something about APIs in the tech news

these days. The authors were seeking to create a sort of common ground that programmers could depend upon so they wouldn't have to worry about the underlying hardware, because, like I said, the underlying hardware was often unique to a specific system. Sometimes even the same computer company might make different models that are in aherently incompatible with one another, which means you would have to relearn everything in order

to develop for the new platform. So yeah, an application programming interface was kind of an approach to sort of create almost like a universal translator just for computer systems, not for people, but for computer systems, so that programmers wouldn't have to specialize in something and potentially end up

becoming obsolete themselves. Right if you were a programmer and you tied yourself down to a specific type of computer, and let's say that that computer company goes out of business, you would have all this knowledge and expertise that was sunk into something that no longer was relevant. That would be disastrous on your part. You would have to start all over again. So APIs could help create a method

for creating bridging material between computer systems. In nineteen seventy four, which is still technically before my time, only by a little bit, a paper by CJ. Date titled the Relational and Network Approaches Comparison of the Application Programming Interface would not only add ing to programs, and now we got application program Ming interface. This paper also expanded the concept of an API, in this case involving databases. So not

just computer systems. Now now we're talking about databases and ways to be able to create a bridging material so that you could access different databases through the same application. This led to the American National Standards Institute as well as the Standards Planning and Requirements Committee to define and adopt API for database management systems. What happened next was that programmers and computer scientists began to develop APIs for

all sorts of computational tasks. We had seen it for database management, and we would see it for other stuff too. These APIs would support different programming languages, so that programmers could make use of the API without worrying about which programming language they needed to use when they were creating the program because not all programmers are fluent in every

programming language, they typically specialize in a couple. In turn, the API would become, as Carl Malamud put it, a way to make quote a set of services available to a programmer for performing certain tasks end quote. Which seems vague in general, but that was on purpose, right. It wasn't meant to pigeonhole API for specific uses, but rather making it an umbrella term for a way of allowing developers to access a set of services that were well

suited for performing certain tasks. It was all about kind of removing some of the challenges to programming right That whole thing about let's not reinvent the wheel. That's kind of what API was all about, was creating these sort of standardized approaches so that programmers could really focus on making better programs with a shorter development process that and

not have to worry about reinvention all the time. Now, I would argue that the types of APIs that we typically talk about today really originate from a dissertation that was made by a guy named Roy Fielding while he was pursuing his PhD. He called his dissertation Architectural Styles and the Design of Network Based Software Architectures. Now that title doesn't scream API, right. If I just saw that title listed on a citation list, I wouldn't immediately think, oh,

that that's a paper about APIs. But it is actually, and Fielding also presented ideas about how APIs work in the age of the Internet. So he wrote this dissertation in two thousand. At that time, there was an emerging technology that would shape the Web and later the mobile Internet, and that was the Web API or the web AP as I would prefer to call it, But then no one would know what I was talking about, so I

won't do that again. But in two thousand, and that same year, Salesforce would release what a lot of folks would point to as the first modern API. In fact, we even have a precise date for this, which is unusual when I'm talking about the history of stuff. Often you can't nail it down to even a specific year. But in this case, we have a specific date February seventh, two thousand. That's because Salesforce actually unveiled this API during

the IDG Demo two thousand conference. The Salesforce API allowed its customers and Salesforce's customers or other companies. Right, Like, you typically have small businesses that are customers of Salesforce and they are essentially offloading certain business needs to Salesforce. Well, in this case, the API would allow these businesses to create an ecosystem in which the businesses could share data across their different applications. So you know, a business can

be really really complicated, right. You can have all these different departments. You can have each department having its own systems you dedicated for that department, which is cool, but it also means that you have the danger of each department becoming a silo so that you can't easily share information from department to department, and that can really end up inhibiting innovation and advancements, and it can be a

big hit on efficiency. So what Salesforce was doing was releasing this API where its customers could make use of this and be able to share across different applications all the same information and make better tools. That would allow for these businesses to operate more efficiently and effectively, and that would be a better end experience for the user, and that philosophy would become sort of an underlying element, a foundational element for APIs moving forward. We're going to

take a quick break. When we come back, i'll explain a bit more about how this would develop over the following years. Okay, we're back, So not too long after Salesforce launched its API, like you know, half a year later, a little more than half a year, eBay would follow suit.

It launched its API in November of two thousand. This would let licensed eBay partners access a framework that would allow the developers to incorporate eBay services into other websites, and technically it would also allow for applications as well. So now like if you were a licensed eBay partner, you could incorporate some of ebase functionality into your own website.

This was a pretty limited version of the API in the sense that you had to be a licensed partner first, and that was not the easiest thing to do, so it was limited in the number of organizations that can make use of the API, but the concept was a strong one. Amazon would follow behind in two thousand and two and it launched its own API as well as it launched Amazon Web Services. Now this was not the fully fledged Amazon Web Services we would talk about today.

That would happen a few years later when we would get introduction of a couple of other big tools, but it was the beginning of a massive move for Amazon, one of the most profitable moves that Amazon would ever make. If you were a developer, this meant you could actually include Amazon functionality on say your web page, and this mud give people a chance to search for products and do some window shopping right from the comfort of your

web page. Maybe you even have your web page dimn't you know, show off products that you're talking about or that are related to whatever the web page is focused on, that kind of thing. And it meant that by incorporating that directly into your web page. People could access that stuff without leaving your site, you know, and your bounce rate would go down and your engagement rate would go way up. Now, it would take a couple more years for other companies to really push into API development. It

was a little slow. These companies were pioneers and others took a bit of time to kind of catch up. For one thing, you have to remember, like two thousand, two thousand and one, that's when we're talking about the dot com bubble bursting, especially in the wake of nine to eleven and here in the United States, and so that would end up taking a lot of the wind out of the sales of companies that otherwise were innovating in the web space. So that I think slowed down

API development. But one of the things we did see in the mid two thousands was the emergence of widgets, which were largely possible because of APIs. Do you all remember widgets? I mean, there's still technically a thing. It's not like they went away, it's just they were really being pushed really hard in the mid to late two thousands on everything from early social media platforms to really

like I remember seeing them everywhere at cees. Right, you would see a refrigerator and it would have widgets, or a television and it had widgets. Everything had widgets on them, and they were always these little icons that linked to some sort of basic functionality. Right. It was usually very specific, like it might be a weather report widget, so you could get a very quick run down on what current and predicted whether conditions are or we're going to be.

Or it might be a stock ticker, or it could be a news headline ticker. You get the idea. It was very specific and purpose built, and it was largely thanks to APIs that it was possible. Right. The widgets were typically tapping into some other platforms information and then presenting that information to you in the form of the widget.

In two thousand and four, Flicker introduced It's API that gave people the chance to embed their images that they had been storing on Flicker on other platforms, including things like web pages or social media. That was incredible, Right, You could have Flicker act as your repository of images, and then you could use the embed feature to share those images on other platforms without having to upload the

same picture to all the different places you wanted. And it really streamlined things, and it really pushed Flicker into becoming a leader for online images for quite some time because they really got ahead of things. In two thousand and six, we had a couple of big APIs that emerged.

One came from Twitter, you know, Rest in Peace. I guess, you know, we could refer to it as X now, but it was Twitter back then and Facebook they both introduced APIs in two thousand and six, and this gave developers a chance to tap into the functionality of those platforms in new ways, and that's kind of what led to third party Twitter feed readers, for example, like tweet deck.

In fact, tweet deck became so useful and popular that Twitter actually acquired it and now it belongs to X And honestly, I'm curious now what it's called, because I imagine it's not called tweet deck within X anymore since they got rid of all the Twitter and tweet stuff and I didn't look it up, so I don't know. I no longer access tweet deck because it's behind a paywall.

But yeah, so developers were able to add in new functions in these new services that tapped into these platforms, and they were functions that you wouldn't find on the vanilla version of the service. So, for example, let's talk about Twitter and tweet Deck. With tweet Deck, a user could create a single view that would incorporate multiple Twitter accounts,

separated by columns. So if you were someone like me, you would have one column that would just show you the incoming Twitter feed, like all the posts from the folks that you follow. You could have a column that shows your own personal Twitter messages as well as the replies and quotes and that kind of stuff, so all the engagement with your own Twitter messages. A third column might show, say, your podcasts tweets and replies and stuff, so it's the same thing as your own personal account,

but for your podcast account and so on. Like, you could have multiple columns stretching across the screen, each one focusing on something separate on Twitter, but all incorporated into a single so you have a very easy way to monitor this. This was really useful for social media managers, right who might be monitoring multiple accounts. Let's say that

you're a manager and you have several clients. You could have a tweet deck set up with all the different client columns there and in a one view you can quickly see what's going on. It's such a useful suite of features that Twitter would buy it, and now Elon Musk has locked it behind a paywall. You have to be a subscriber to access those features. So yeah, bumber.

It's why I don't really check tech Stuff's Twitter feed anymore, because I had it incorporated into tweet Deck, and now I can't access tweet Deck because I'm not a subscriber, So yeah, it's kind of lost. I could technically log into x and tech Stuff's account and check it that way, but y'all, it's just the mental energy needed for me

to do that just doesn't exist in me anyway. Facebook's API would let developers create all sorts of stuff that could be built on top of Facebook, including things like games and surveys and all that sort of stuff. This is what eventually led to the Cambridge Analytica scandal, in fact, because a developer created a survey tool that was paying

people to take the survey. But what the people didn't know is that by agreeing to the survey, which was all based integrated into Facebook using Facebook's API, then the actual survey could gather information not just about the person taking the survey in the first place, but all the people they connected to through Facebook, like if their friends had public Facebook profiles, the app could then access all

of that information as well. So that's what led to a big scandal, because it meant that the app developer was able to access information from people who never consented to share that information in the first place. Facebook ultimately changed its API to restrict apps so that they could only request access to info that was relevant to whatever the app was doing. So that way, if you were to download or install an app that was like a fun horoscope app, it wasn't for some reason getting access

to all your messages and stuff like that. That would not be necessary for that particular app. But back in the old days there were fewer restrictions, and we saw what happened as a result of that. In two thousand and seven, we had another huge development that would have a big push on APIs, and that was the introduction of the iPhone. So I've said this before, the iPhone was not the world's first smartphone. It had followed behind

lots of other smartphones. But before the iPhone, particularly here in the United States, smartphones were not really a consumer product. They were sort of a prosumer product. It was the kind of thing you would expect a business executive to own, like a BlackBerry, something like those types of smartphones. But your average person didn't have a smartphone. That's not how

they accessed the web. If they were accessing the web at all, they were doing so on a desktop or laptop computer, maybe a web TV if they were one of those folks, but otherwise you were accessing it on like a computer. The iPhone would change that, right, and that would mark the beginning of what would become a massive shift in web development and web design, this migration to the mobile web. As more people adopted smartphones, there was this need to make it easier for those folks

to view and interact with online content. Right, Like, you couldn't just present a web page to a smartphone the same way you would to a PC or laptop because the landscape was to different, right, the size of the screen was different. It would make it very challenging to read or interact with stuff that was on a web page. You had to come about it in a different way.

But that also meant that there were new opportunities to develop applications that were built on top of APIs that could work specifically for smartphones, that could lay things out in a way that made it easier to interact with the content that was on the web. So the mobile web really created a huge, huge change in the approach to APIs. And there was another one that was going on at the same time, and that was the shift

to the cloud. This was happening more in the background, but you had more and more companies that were taking advantage of cloud services in order to offload things that traditionally would have to all happen in house. Right, So in the old days, if you had a company that had its own databases and computer systems and stuff, you had to keep all of that stuff on premises. You were responsible for keeping up with all the hardware, maintaining

the software, updating features, that sort of stuff. That's a lot of work. But cloud services offloaded a lot of that and really made it possible for software as a service to emerge. I'll talk a little bit more about that in just a second. We're going to take another quick break and we'll be right back. So, yeah, I

mentioned before the break the emergence of cloud services. Now, they did exist before the mid two thousands, but it was right around that time where they started to really take off, and in fact, we could point to two thousand and six as being a huge year for that because that's again when Amazon would introduce some new features in the cloud, like Amazon Compute and Amazon Storage services

that would become hugely influential in the space. In fact, it made Amazon become the dominant player in the cloud computing space in many ways. So now you had the ability for businesses to tap into functionalities that otherwise they would have to develop all in house and it might take them years to do or it might be such a big investment that they never would be able to

do it. Now, by becoming customers of these cloud computing companies, they could end up offloading the compute and storage stuff to another company and get their developers to create new applications that tapped into that ability and leverage the information that the business was gathering. So it became possible to

create entirely new services. And this is really when we started to see software as a service explode as a business model, because developers could create a tool that would meet the needs of their customers and then charge their customers, maybe even setting up a subscription service for their software, and that would turn an application into an ongoing revenue generator. Like in the old days. Let's say you made a

word processing program. You would sell that in stores and you would get a portion of every sale that was made. Right that was the old day of days of programming. You'd make a program, people would buy a copy of the program, you hope that not too many people pirated your stuff, and you made money. Software as a service

is totally different. You would make an application and you would sell access to that application, which would be based in the cloud, built on APIs, tapping into all these powerful other platforms, and your customers would pay you an on going subscription fee to access that tool, and you would be able to make money off the same application with the same customer over and over again, as opposed to doing it that one time and that one point of sale. So it really was a truly enormous change

in business. These days, APIs allow developers to make tons of new products and services by building on various foundations. Typically, the developers are also paying for the use of APIs. I mean it depends. The platform may have a tiered list of API access with a free tier at the bottom, which might limit the features that developers can tap into, or maybe a charge based upon how frequently the app that the developers working on is going to reference the

underlying platform. So when we say reference, what we're talking about is the app itself, the end app how frequently does it have to access the underlying platform. So if you've built a Twitter based app, for example, or X, I guess we should say an X based app. How frequently is that app referencing X? How quick? How many times does it have to pull information from or post information to the underlying platform? That would be a reference.

And one way that companies will charge developers is by adding up the number of times their apps are referencing the underlying platform and saying, all right, you are putting X demand on this platform. Shouldn't use X since that is a platform. You're putting this specific amount of demand upon our platform. In turn, we are going to charge you this amount because you are putting this load on

us in order to power your application. So this has actually led to some issues recently which I've td about on this show, but you've probably also just heard out and about which is that A couple of different companies, specifically x formerly known as Twitter and Reddit, have alienated some developers by changing up their API. So by doing things like getting rid of free tiers of service and hiking up the cost of other tiers, these companies have

really upset a lot of developers and users. So these companies are charging developers based on essentially how frequently the apps are referencing those underlying platforms. So Reddit is a great example. Reddit did this thing where they changed how much they were charging developers for really popular apps. So let's say that you've made a Reddit app, and really this let's just say, this app is just a way to browse and post to Reddit. Right, we're not reinventing

the wheel. We're not making anything spectacular. What we're making is a Reddit tool that lets you, you know, access subreddits, read posts, and make posts. And that's it. But it's got a really good user interface, it's really well organized,

easy to use, its attractive. Uh, it's got you know, things in places that make a lot of sense, and a lot of users see it as being superior to the official Reddit app, So they gravitate toward this third party app that you have developed because they just like the way that you've approached this, but your app has become really really popular and people are using it a lot.

It's not just that a ton of people have downloaded and installed your app, it's that they're on the app all the time, and so your app is referencing Reddit

a lot. Every single day. Reddit is tallying up those references, and then it sends you a bill, and that bill is truly massive, like we're talking like millions of dollars a year massive, And meanwhile, your app is not really generating that much revived Like maybe you built this app and maybe you are making some money off of it, but it's nothing compared to the bill that's coming in.

So you literally cannot afford to stay in business because the bill you have to pay to Reddit is greater than what you're making in revenue, so you have to

shut down. This is what happened over at Reddit. Some very popular Reddit third party apps had to close up shop because they couldn't afford to stay in business, and a lot of the Reddit community got extremely upset about this and felt that Reddit was pricing out third party developers and trying to force people into using the actual Reddit app, which a lot of people did not like, and as a result, we saw lots of protests on Reddit. Subreddits went dark for a couple of days, some longer

than just a couple of days. Now there's this ugly business of Reddit coming in and removing moderators of certain subreddits who were refusing to give up on protesting this change, and it's continuing to this day. It's still ugly. There are still some subreddits that are feeling the effects of this. The leadership at Reddit haven't really budged on the issue, and meanwhile, the users are just as angry now as they were earlier this summer when the changes were first

kind of coming to light. So APIs can be a big, big deal, right. They can be a big revenue generator, They can be a big way to build loyalty in a customer base. But they can also be at the heart of great controversy if a company decides to make changes to its policies and at least in the eyes of the public, disproportionately hurt the developers who are making use of those APIs. So I hope this episode helps clear up what APIs are, what they're for, and why

they are important. They are the thing the gateway that allows into developers to tap into the massive features that are found in really important platforms and to create new

experiences for people that we have. If I were to do an episode just on a list of apps that companies bought because the apps that were developed by third parties were better than the stuff that was coming directly out of the company itself, that would be an epic episode because there are countless versions of that, and it really just shows that, you know, innovation is not something

that you can just contain within four walls. Innovation comes from entire communities and people who are only tangentially connected to the actual underlying you know thing, and it's much better to allow that kind of innovation to flourish because we get the best tools and best experiences that way. And I don't think it really profits anyone for love

that down too much. I mean, I get the need to generate revenue to an extent, but I feel like the extent we have seen has far outstretched creduelty, let's say. In other words, I don't necessarily believe it when Reddit says that they have to put in these exorbitant fees in order to pay their Internet bills. I don't know

that that's really that. I'm sure there's some truth to that, but I don't know that it necessitates charging a developer millions of dollars a year because their app is so popular. I hope you are all well. I hope you enjoyed this tech Stuff Tidbits episode, and I will talk to you again really soon. Tech Stuff is an iHeartRadio production. For more podcasts from iHeartRadio, visit the iHeartRadio app, Apple Podcasts, or wherever you listen to your favorite chops