Why Can’t Us Consumers Have APIs
summary
Argues that consumers should each run a personal server exposing a small CRUD API so apps plug into user-controlled data rather than silos, specifies SEPS 1.0 for read/write/update/delete endpoints and SEPS 2.0 for server-to-server auth and sharing (GNAP-inspired token flow). Demonstrates a proof-of-concept called Freezer that stores data on Google Drive/Dropbox/AWS or Swarm, uses OAuth2 for app permissions, and successfully shares highlighted article snippets between two browsers; Freezer is production-used by the author but remains a proof‑of‑concept.
AI-written summary · about
chapters (8)
- 0:00Start
- 1:00Why Can't Us Consumers Have APIs
- 2:41B2C: Heteronomy
- 3:54A Hypothetical...
- 8:34Freedom of Association
- 13:43Freedom of Movement
- 15:26freezr-Storage API
- 19:56Building Blocks for a Consumer API
related talks
18mSimplifying Consuming APIs for SDK Haters
27mAPI Economy and Ecosystem
27mHow API and Low/NoCode can empower citizen developers
32mBuilding Apps with an API-based Backend
27mUser focused API Design
27mBuilding Great Web APIs
28mAPIs should be products, devportals too - or shouldn't they?
30mConsumer APIs Must be Product-Driven