Building a Swift Web API
summary
Built a Swift web API that replaces an old backend without changing the iOS client by keeping the interface decoupled and using hypermedia controls (RFC5988 link headers, embedding via HAL and richer actions via Siren). Implementation uses a tiny routing library (Frank) rather than a monolithic Kitura/Vapor stack, tests API contracts with Dredd against an API Blueprint, deploys to Heroku (or Bluemix/Docker), and runs with log aggregation (Papertrail); clients keep working during the rewrite.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:40API Design
- 1:06What makes a good API?
- 1:21Example: Pagination
- 3:43How do we introduce changes to our API?
- 4:52API is coupled to implementation details
- 5:36What happens when you version an API?
- 6:13How can we design the API without exposing implementation details?
- 6:47Anticipating change is one of the central themes of REST
- 7:09Tight Coupling
- 7:42Controls have to be learned on the fly. That's what hypermedia enables
- 8:02Web Linking RFC 5988
- 12:55Building an API in Swift
- 13:15Web Frameworks
- 14:06Frank vs Kitura vs Vapor
- 14:40Server APIs Working Group
- 18:32Manual Deployment
- 19:02Papertrail
related talks
58mBackend in Swift: It Exists and Works!
23mServer-side Swift with Kitura
39mBYOB: Build Your Own (Swift) Backend. Server-Side Swift beyond CloudKit
10mServer-Side Swift: Surviving or Thriving?
47mServer Side Swift with Vapor
24mServer-Side Swift from Scratch
34mServer Side Swift
27mFull Stack Development with Swift and Vapor