A Developer's-Eye View of API Client Libraries
summary
A concrete checklist for usable API client libraries: claim that good libraries stop developers banging their heads by handling HTTP, auth, parsing and deprecations; use real tools like Python packages installable via pip install mylibrary and adapt HTTP libs to handle rate limiting and sensible user agents; prefer clear, idiomatic names such as page.text/page.save; provide findable, runnable examples, tests that localize API vs code errors, documented corner-case hacks, an explicit license and a welcoming code‑of‑conduct so contributions behave.
AI-written summary · about
chapters (16)
- 0:00Start
- 4:27Basic assumptions
- 7:45Mobile development
- 9:08Why use a client library?
- 11:02The API wasn't designed for your goals
- 14:47Add abstraction
- 17:22Findable and accurate documentation
- 18:24What does it do? What's it good for? What isn't it good for? Which versions of the API?
- 20:43Take advantage of existing skills, platforms, tools, packaging systems
- 23:26Follow principles of good API design
- 23:49Use self-explanatory, unambiguous names
- 25:20Separate layers of abstraction
- 30:35Set accurate expectations
- 31:24Make your community welcoming
- 35:24Resources
- 37:43OPEN SOURCE BRIDGE
related talks
49mAdvanced API design: how an awesome API can attract friends...
27m5 Features of a Good API
26mDesigning Accessible APIs
42mGood APIs don't need a tutorial
22mMake your APIs Developer-friendly
27mUser focused API Design
35mPrinciples of Awesome APIs and How to Build Them
47mBuilding APIs your users will want to use