Client libraries are better when they have no API?

Original Article ↗ Hacker News Discussion ↗

What “no API” is arguing for

  • Many interpret “no API” as misleading, since HTTP endpoints and URI schemes are still interfaces.
  • Several commenters read the point as: avoid bespoke client libraries and new method surfaces; instead, integrate with tools and protocols users already know (e.g., Pandas’ read_csv) and let agent detection/content negotiation “do the right thing.”
  • Some find this elegant: you just use a csvbase:// URI; no extra client class or methods to learn. Others argue that this is still an API, just a very thin one.

fsspec plugin model and URI schemes

  • Discussion highlights how fsspec lets developers implement custom filesystems with minimal code and automatically expose them to multiple libraries (Pandas, Polars, Dask, DuckDB).
  • Enthusiasts like that installing a package adds support for a new URI scheme everywhere fsspec is used, enabling composition and ecosystem effects.
  • Skeptics worry that “pip install” silently changing runtime behavior via entry points is dangerous and surprising.

Hidden magic vs explicit configuration

  • Strong discomfort with hidden monkeypatching or plugin auto-registration: hard to discover, debug, or reason about, especially during outages or refactors.
  • Some prefer explicit registration calls or explicit passing of filesystem objects, even if slightly more verbose.
  • This is framed as “convention over configuration” versus “explicit is better than implicit”; several point out maintenance and debugging costs, action-at-a-distance, and unclear dependencies across time.

API ergonomics, access control, and payments

  • Several comments complain about “annoying APIs”: multiple keys, forced project/account setup, SMS 2FA, complex OAuth flows.
  • There is a side discussion about alternative payment and anti-abuse models (e.g., simple pay-per-call, crypto-based) versus identity-based accounts; no clear consensus.

CSV and data format trade-offs

  • Some praise CSV as convenient for tabular data and compatible with existing tools.
  • Others call CSV a “terrible” or underspecified format, citing ambiguity around nulls, escaping, separators, and newlines; they prefer JSON, JSON Lines, Parquet, or even XLSX.
  • Commenters note that none of the formats is ideal: JSON is verbose, CSV messy, Parquet complex and less stream-friendly.

General takeaways

  • Many like the article as a demonstration of building on existing abstractions instead of reinventing client libraries.
  • There is sharp disagreement on whether the convenience of auto-wired plugins and URI schemes is worth the hidden complexity for long-term maintenance.