Welcome to the History of Computing Podcast, where we explore the history of information technology. Because by understanding the past, we’re able to be prepared for the innovations of the future! Todays episode is gonna’ be a bit boring. It’s on APIs. An API is an Application Program Interface this is a set of tools, protocols or routines used for building applications. See boring! Most applications and code today are just a collection of REST endpoints interconnected with fancy development languages. We can pull in a lot of information from other apps and get a lot of code as we call it these days “for free”. It’s hard to imagine a world without APIs. It’s hard to imagine what software would be like if we still had to write memory to a specific register in order to accomplish basic software tasks. Obfuscating these low level tasks is done by providing classes of software to give developers access to common tasks they need to perform. These days, we just take this for granted. But once upon a time, you did have to write all of that code over and over, on PCs, initially in BASIC, PASCAL, or assembly for really high performance tasks. Then along comes Roy Fieldings. He writes the Architectural Styles and Design of Network-based Software Architectures dissertation in 2000. But APIs came out of a need for interaction between apps and devices. Between apps and web services. Between objects and other objects. The concept of the API started long before y2k though. In the 60s, we had libraries in operating systems. But what Subrata Dasgupta referred to as the second age of computer science in the seminal book by the same name began in 1970. And the explosion of computer science as a field in the 70s gave us the rise of Message Oriented Middleware and then Enterprise Application Integration (EAI) becomes the bridge into mainframe systems. This started a weird time. IBM ruled the world, but they were listening to the needs of customers and released MQSeries, to facilitate message queues. I release message queues are boring. Sorry. I’ve always felt like the second age of computer science is split right down the middle. The 1980s brought us into the era of object oriented programming when Alan Kotok and his coworkers from Xerox PARC gave us Smallltalk, the first popular object oriented programming language and began to codify methods and classes. Life was pretty good. This led to a slow adoption across the world of the principals of Alan Kay vis a viz Doug Engelbart vis a viz and Vanever Bush. The message passing and queuing systems were most helpful in very large software projects where there were a lot of procedures or classes you might want to share to reduce the cyclomatic complexity of those projects. Suddenly distributed computing began to be a thing. And while it started in research institutes like PARC and academia, it proliferated into the enterprise throughout the 80s. Enterprise computing is boring. Sorry again. The 90s brought grunge. And I guess this little uninteresting thing called the web. And with the web came JavaScript. It was pretty easy to build an API endpoint, or a programmatic point that you programmed to talk to a site, using a JSP or JavaServer Page helps software developers create dynamically generated pages such as those that respond to a query for information and then pass that query on to a database and provide the response. You could also use PHP, Ruby, ASP, and even NeXT’s Web Objects, the very name of which indicates an Object Oriented Programming language. The maturity of an API development environment led to Service-Oriented Architectures in the early 2000s, where we got into more function-based granularity. Instead of simply writing an endpoint to make data that was in our pages accessible, we would build those endpoints to build pages on and then build contracts for those endpoints that guaranteed that we would not break the functionality other teams needed. Now other teams could treat our code as classes they’d written themselves. APIs had shot into the mainstream. Roy Fielding’s dissertation legitimized APIs and over the next few years entire methodologies for managing teams based on the model began to emerge. Fielding wasn’t just an academic. He would help create the standards for HTTP communication. And suddenly having an API became a feature that helped propel the business. This is where APIs get a bit more interesting. You could transact online. eBay shipped an API in 2000, giving developers the ability to build their own portals. They also released low-code options called widgets that you could just drop into a page and call to produce a tile, or iFrame. The first Amazon APIs shipped in 2002, in an early SOAP iteration, along with with widgets as well. In fact, embedding widgets became much bigger than APIs and iFrames are still common practice today, although I’ve never found a *REAL* developer who liked them. I guess I should add that to my interview questions. The Twitter API, released in 2006, gave other vendors the ability to write their own Twitter app, but also gave us the concept of OAuth, a federated identity. Amazon released their initial APIs that year, making it possible to use their storage and compute clusters and automate the tasks to set them up and tear them down. Additional APIs would come later, giving budding developers the ability to write software and host data in databases, even without building their own big data compute clusters. This too helped open the doors to an explosion of apps and web apps. These days they basically offer everything, including machine learning, as a service, all accessible through an API. The iPhone 3g wasn’t boring. It came along in 2009. All of a sudden; and suddenly the world of mobile app development was unlocked. Foursqure came along at about the same time and opened up their APIs. This really gave the whole concept of using other vendor APIs as a way to accomplish various tasks without having to write all the code to do some of those tasks themselves. From there, more and more vendors began to open APIs and not only could you pull in information but you could also push more information out. And the ability to see settings gives us the ability to change them as well. From the consumer Foursqure to the Enterprise, now we have microservices available to do anything you might want to do. Microservices are applications that get deployed as modular services. Private APIs, or those that are undocumented. Public APIs, or interfaces anyone can access. Partner APIs, or those requiring a key to access. At this point, any data you might want to get into an app, is probably available through an API. Companies connect to their own API to get data, especially for apps. And if a vendor refuses to release their own API, chances are some enterprising young developer will find a way if there’s an actual desire to leverage their data, which is what happened to Instagram. Until they opened up their API at least. And Facebook, who released their API to any developer well over a decade is probably the most villainized in this regard. You see, Facebook allowed a pretty crazy amount of data to be accessible in their API until all of a sudden Cambridge Analytica supposedly stole elections with that data. There’s nothing boring about stealing elections! Whether you think that’s true or not, the fact that Facebook is the largest and most popular social network in the history of the world shines a light when technology currently being used by everyone in the industry is taken advantage of. I’m not sticking up for them or villainizing them; but when I helped to write one of the early Facebook games and I was shown what we now refer to as personally identifiable data, and able to crawl a user to get to their friends to invite them to add our game, and then their friends, it didn’t seem in the least bit strange. We’d done spidery things with other games. Nothing weird here. The world is a better place now that we have OAUth grant types and every other limiter on the planet. Stripe in fact gave any developer access to quickly and easily process financial transactions. And while there were well-entrenched competitors, they took over the market by making the best APIs available. They understood that if you make it easy and enjoyable for developers, they will push for adoption. And cottage industries of apps have sprung up over the years, where apps aggregate data into a single pane of glass from other sources. Tools like Wikipedia embrace this, banks allow Mint and Quickbooks to aggregate and even control finances, while advertising-driven businesses like portals and social networks seem to despise it, understandably. Sometimes they allow it to gain market share and then start to charge a licensing fee when they reach a point where the cost is too big not to, like what happened with Apple using Google Maps until suddenly they started their own mapping services. Apple by the way has never been great about exposing or even documenting their publicly accessible APIs outside of those used in their operating systems, APNs and profile management environment. The network services Apple provides have long been closed off. Today, if you write software, you typically want that software to be what’s known as API-first. API-first software begins with the tasks users want your software to perform. The architecture and design means the front-end or any apps just talk to those backend services and perform as little logic not available through an API as possible. This allows you to issue keys to other vendors and build integrations so those vendors can do everything you would do, and maybe more. Suddenly, anything is possible. Combined with continuous deployment, contiuous testing, continuous design, and continuous research, we heavily reduce the need to build so much, slashing the time it takes to market and the cost it takes to get to market substantially. When I think of what it means to be nimble. No matter how big the team, that’s what I think of. Getting new products and innovations to market shouldn’t be boring. APIs have helped to fulfill some of the best promises of the Information Age, putting an unparalleled amount of information at our fingertips. The original visionary of all of this, Vannevar Bush, would be proud. But I realize that this isn’t the most exciting of topics. So thank you for tuning in to yet another episode of the History of Computing Podcast. We’re so lucky to have you. Have a great day!