tfl.fyi: Building Human-consumable APIs
summary
A prototype called tfl.fyi fetches TfL’s unified API every 30 seconds into Node.js worker threads, pre‑processes responses into tiny request objects and serves a single HTTP payload so users underground get status with one single HTTP request. It handles fuzzy free‑text stop searches, hides messy natpan/ICS IDs, and avoids dozens of concurrent calls that kill low‑bandwidth connections. The service proves the approach is viable though it has occasional outages; major takeaways: version APIs, timestamp UIDs, and provide dummy data.
AI-written summary · about
chapters (11)
- 0:00Introduction and welcome
- 2:29How TfL’s transport system works
- 8:28Challenges with TfL’s API
- 12:58Real-world complexities of transport data
- 16:49Problems with inconsistent API payloads
- 17:52Introducing tfl.fyi project
- 18:13Architecture of tfl.fyi
- 20:41Designing the API surface
- 22:06Lessons learned from TfL’s API
- 23:29Building APIs for human users
- 23:50Closing and call to action
related talks
13mAPIs in the public transport industry — what's next?
26m5 billion API hits that have accelerated customer outcomes
55mGive it a REST - Tips for designing and consuming public API's
19mLessons learned -- two years with Trafiklab
14mRevolutionize Traffic Management with Open APIs: Learn How!
26mFrom project to reality let's explore some API
05mUnlocking Real-Time Data
24m"Good luck with that": Tag Teaming Civic Data