In context, you're right of course. But you might be underestimating the number of non-web programmers who have this reaction. I know many such people, and many have asked me "The term API predates the web; In what sense is this an API?".

For such people, I propose the metaphor that HTTP APIs are a form run-time linking where the root URL (api.example.com) is the "library" and the valid URIs (api.example.com/list_of_cats) are the exported "symbols" you can reference from your program. Performing a GET on such a "symbol" is like dereferencing the pointer you get from calling dlsym. The 400 and 500 range status codes are like dlsym's error codes: 404 is a failure to find the symbol, 500+ is various run-time errors, etc.

Thank you! Perfect response. I'm a systems programmer, mostly working in VHDL, C and assembly. I use and write API's all the time. I've never used an "API" over HTTP before.

I think the confusion comes from a slow divergence of terminology. Web providers offered "API's" to allow people to access their services, these were kind of API's in the sense that an application could use them. However, it seems that for the web development community has begun to think that an API and an HTTP based API are synonymous (they are not!). Hence my confusion here.