For a web developer, it is a rite of passage to learn what a web API is. Everyone and their grandmother has probably used one, and if someone were curious enough to ask what it is, they would be met with articles upon articles, from GeeksForGeeks, IBM, AWS, FreeCodecamp, Wikipedia, Coursera, Cloudflare, Oracle, Github, and many, many other sources, answering that exact question. So I think it's safe to say that that request has a response, and a unanimous response at that: an API is an Application Programming Interface, or thing by which a client communicates with a server.
Putting aside, of course, the confusion and vagueness caused by the acronym referring to both programming interfaces in general and programming interfaces on the web, we can say the mystery is solved, thanks to the heroic efforts of developers upon developers fulfilling another rite of passage: explaining APIs to someone else.
But despite how thoroughly this dead horse has been beaten, there is still a missing piece of the puzzle. APIs are a tool, so it's meaningless to describe what they are without explaining why we need them. While "Application Programming Interface" accurately encompasses the concept, it's a definition that is akin to calling a screwdriver a "handheld thing for turning screws"—it begs more questions than it answers. So what are these Applications? Why do they need Interfaces? Why is everything a request? In short, why is an API?
There are reasons not to have APIs. It is not a given that their core function, which is transferring data over the web, is needed to build an app. Consider desktop or mobile apps. To personalize them, user data can be stored on the user's device, no HTTP requests needed. And data that is needed to run the app is downloaded when the app is installed (why aren't web apps installed, anyway?). In contrast, web app data is usually stored by the app's provider, not the user. If this storage pattern was not already ubiquitous, it would be bewildering—why can't I just store my own data? Why do I have to prove my authenticity to someone else to access my own data? The answer is rooted in the evolution of the web.
Document origins
There was once a time when nobody used web APIs or asked what they are or explained them to people asking what they are. Back then, the internet was used by researchers to exchange text documents. To address the limitations of plaintext, these researchers invented a markup language that could quickly link (hyperlink) to other documents, and HyperText Markup Language, or HTML, was born. Thus, these researchers built the World Wide Web to transfer these HyperText documents over the internet via the HyperText Transfer Protocol, or HTTP.
These researchers had particular needs. They didn't need user accounts or AI chatbots; they just needed document retrieval, so HTTP was developed with one type of request: GET. A pretty self-explanatory HTTP method, the user specifies a document using a Uniform Resource Locator (URL) and the server responds with the document.
Because documents were meant to be viewed and navigated through but not necessarily kept, as the web was decentralized and not a static body of media, browsers were made to download them but not store them. This transience is the design decision that has defined the structure of websites to this day. It is why browsers always need to make requests, why you access web apps like Google or Amazon or Netflix by "visiting" their URL instead of opening a desktop app.
At some point, as websites were being used more and more as software instead of documents, it made sense to retrieve program-formatted data without requesting a whole user-friendly document. Thus, the API was born, as the interface of URLs and HTTP methods through which a server supplies this program-formatted data. And so the mystery is solved: APIs exist to satisfy a need for programmatic data retrieval in websites that are pieces of software designed for a web that was designed for documents.
Software fate
Now, with the web being used for all sorts of wacky things beyond distributing research papers, its new users have particular needs. As such, it has evolved to do away with many of the limitations imposed by those early design decisions. While browsers originally did not install websites, they now do, with Progressive Web Apps (PWAs) and service workers. While browsers originally did not store user data, they now do, in the form of cookies and "local storage," among other things. And while browsing was originally stateless, it now isn't, with user authentication made possible over stateless HTTP by the aforementioned cookies and local storage.
These days it feels like APIs are a quirk that developers must adapt to, but the reverse is true. The web is a piece of infrastructure designed and adapted to fulfill the particular needs of developers, and APIs are one of those adaptations. That is why an API.