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 r

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.