It's become just a word that means "interface endpoints". And frankly that's fine, it's what it is in the end. Whether in an OS, a website, or another platform.
The other way around, the meaning of API standalone has been narrowed to mean HTTP APIs, as if it were redundant. Specially tedious if you're searching for non-HTTP API design notes.
> The other way around, the meaning of API standalone has been narrowed to mean HTTP APIs (...)
I don't think so. The pervasiveness of web apps and applications consuming web services means there's a lot of work involving web APIs. This doesn't mean the definition of API was narrowed. It's all about context. If your bread and butter is developing web services, you don't waste time with context-free definitions of your API. You talk about the API and everyone is on the same page.
If all anyone ever talks about is APIs in the web services sense then, yes, the definition of API has been narrowed. When everyone will assume you mean web services API when you refer to an API and have to use extra words to describe non-web APIs then the definition has narrowed. That's how English works: the definitions of words depend on their usage and dictionaries describe how words are used.
You even admitted "The pervasiveness of web apps and applications consuming web services means there's a lot of work involving web APIs" and "If your bread and butter is developing web services, you don't waste time with context-free definitions of your API" which is acknowledging the common use definition of API has morphed into Web API. It's only in the context of technical documents or documents that are explicitly referring to non-web APIs that use API and it is understood to mean something other than a web API.
Almost all my development has been in the fields I mentioned. I prefer to think of HTTP 'APIs' as end-points instead: you query a URL for some fields, and you receive some data—whether it be plaintext (JSON), or binary. That's essentially it. I feel narrowing the definition of an API to just 'HTTP end-points' is very reductive. The word stands for 'application programming interface', but I don't really need to program anything to use a HTTP end-point: I can navigate to it using a Web browser, if I want.
For me, an API is a lot more concrete: a set of data structures (whether they be classes, objects, pairs, tuples, lambda functions, etc.) with extensible functionality (member functions, pure functions accepting those data structures, etc.) that developers can use independently, or together, to produce some new functionality, i.e. program using interfaces.
So what I'd traditionally think of APIs are the .NET API, the C++ STL, the Java API, the Windows API, the Linux headers, Qt, GTK, even React.
I always thought of API in the sense of POSIX Or NFS etc. A common interface that existed across different libraries regardless of the vendors. Designed for interoperability.
Well, to be fair, libraries and SDKs do have APIs, it's what you mainly interact with when you use them, the defined interface that you programmatically use in your application.
You create a "web-service" and then describe it by describing its "interface" you are in fact creating that interface. That is how it is on the web because the web-tech does not give us a language in which to describe service-endpoints.
In non-web development the APIs can be described formally as function-signatures in any statically typed programming language.
Or is there some simple language in which to write descriptions of web-services?
Of course, there are tons, they're generally called IDLs (interface description languages), common examples are Protobufs, Avro, Thrift, etc.
They're not hugely popular for web services largely because the web was designed to avoid exactly this kind of a priori contractual requirements between communicating parties. But that's a much bigger conversation.
Desktop, embedded, video games, HPC suddenly cried out in terror and were suddenly silenced.