One of the things that people say sometimes (including about serving static files on the web) is that "the filesystem is an API". On a superficial level this sounds fine. The abstracted form of a filesystem hierarchy is a common interface between programs, one that you can write code to use; you can create files and directories, inspect the hierarchy, read data that has been put in there, and delete things again (if you have permissions).

However, I've come to feel that the filesystem as a thing (abstract or otherwise) doesn't particularly feel like other APIs. Filesystems are program-independent hierarchical namespaces with some operations and types of entities that we all agree on (and a number of both that we don't; consider Unix symbolic links and hard links). But they aren't hard, nailed down interfaces for programs to code against in the way that other APIs are. The abstract idea of "the filesystem" has no defined content or structure (that's up to any particular use you make of the idea), and as far as actual program code goes we merely have a general agreement on the names for common operations and common filesystem contents ('files' and 'directories'). Different programming environments and even operating systems implement somewhat different actual APIs for filesystem access and manipulation, especially once you get out of the very basic operations.

(Even the idea of 'the contents of a file' is somewhat fuzzy. Is that a binary file or a text file? In some environments, the difference matters.)

If you say that the filesystem is an API, I feel that you're saying about as much as if you said that the web (as an idea and a general thing) is an API (which is true but in a very broad, architecture astronaut way). The filesystem being an API is pretty much the idea that you can use a commonly agreed on hierarchical namespace to communicate between programs, and between people and programs.

One place where this matters is if people aspire for other, more concrete APIs to become as broadly adopted and available as the filesystem "API". I feel that that would require people transforming those more concrete APIs into something more or less as broad, encompassing, and general as the idea of filesystems. For many things that people want to be broad APIs, I tend to not see any obvious path for that to happen because there doesn't seem to be a level between a broad idea and a concrete API.

(In part, there's a bit of me that bristles at calling the filesystem or the idea of filesystems an API, and I want to figure out what my objection is. I'm not sure I fully understand my objections yet.)

PS: You can use a filesystem to make a concrete API, or as part of a concrete API, but that's a different thing. You have one or more programs that's ascribing particular meaning to a hierarchy with specific contents, and specific manipulation of the contents may have specific effects.