3 ms·
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," t
by thomascgalvin 3y ago
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.
- lenerdenator 3y ago> 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.
- actionfromafar 3y agoNot much use then either, it's like encased in resin. Limit the ability to provide input, maybe?
- magicalhippo 3y agoAnd users. We wouldn't have nearly as many issues if it weren't for those darned users...
- lenerdenator 3y agoPEBKAC vulnerability still unpatched all these decades later.
- layer8 3y agoIt 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).