←back to thread

428 points ahamez | 3 comments | | HN request time: 0.418s | source
Show context
zahlman ◴[] No.45008539[source]
Anyone else old enough to remember when "API" also meant something that had nothing to do with sending and receiving JSON over HTTP? In some cases, you could even make something that your users would install locally, and use without needing an Internet connection.
replies(8): >>45008634 #>>45008640 #>>45008724 #>>45008781 #>>45008898 #>>45008932 #>>45009194 #>>45009303 #
1. chubot ◴[] No.45008640[source]
Well it stands for “application programming interface”, so I think it is valid to apply it to in-process interfaces as well as between-process interfaces

Some applications live in a single process, while others span processes and machines. There are clear differences, but also enough in common to speak of “APIs” for both

replies(2): >>45012793 #>>45017180 #
2. zahlman ◴[] No.45012793[source]
It certainly is valid. I'm just irritated that it's taken over to the extent that it has.

Just as I am irritated that people seem to have forgotten that "applications" can potentially run completely locally, and that programs can be designed around the assumption that the "front end" (UI) and "back end" (business logic) will communicate directly (or at least exist within the same process, even if there are good reasons to set up message queues etc.).

But, you know, that's bad for business. Because that entails that the consumer might actually get to own something, even if it's just an ephemeral pattern of bits on local storage.

3. 1718627440 ◴[] No.45017180[source]
In my knowledge, there is the distinction of API vs. protocol, i.e. whether you use the foreign software through calling into it or by serializing and sending somewhere. "web APIs" seam to be the latter not the former, so I don't get why they got christened APIs.