My initial reaction was also "if I can talk to your software, that's an API."

Reading through the article, though, the author isn't advocating for "no APIs," they're advocating for minimalist APIs that use agent detection to "do the right thing."

Chrome tells the API that it can accept HTML, so the server sends data formatted inside of a web page, with an HTML table.

Curl doesn't send that header, so the server sends unformatted CSV. But you could send an Accept header to get the HTML if you wanted.

The benefit of this is that for most use cases, this will "just work."

The downside is, if you want to view the CSV in a browser, or the web page in curl, you need to know (or guess) how the server is deciding what to send you, and take the correct action. An API documented with OpenAPI, while more complicated, explicitly tells you what you can do.

> My initial reaction was also "if I can talk to your software, that's an API."

I've long held that software ages far better if you just eliminate the ability of people to provide it input.

And users. We wouldn't have nearly as many issues if it weren't for those darned users...

PEBKAC vulnerability still unpatched all these decades later.

Not much use then either, it's like encased in resin. Limit the ability to provide input, maybe?

It just transfers part of the complexity to “I have to know this will send CVS” and “which flavor of CVS?” and “what will the CVS columns be?”, and so on. In the end, you still have to know the format, and, as opposed to a programming-language library API, it’s less discoverable, tends to be less documented, and mostly untyped (a Python API could at least be gradually-typed).

I personally thought the author was pretty clear in the article. My interpretation is that there is no `csvbase-client` API for a user to learn, manage, or even import. The end user continues using their preferred dataframe library, but now has access to data via the "csvbase://" URI as if it was a csv file on their local file system.

It seems to mean no API that is new, unfamiliar, or something to that effect for the user to learn. You can use the Pandas, Polaris, etc. APIs that you are already already accustomed to.

Have you never used a client library that provides its own API that wraps the web API? Something like Stripe, where you have domain objects and helper functions and other incantations that are layered on top of the bare http?

That's what the author is saying they don't have. When you import their client library you just have a new URI scheme you can use anywhere that accepts a URI, not layers of extra classes and methods to learn how to interact with.