API Design in Python

What your seat includes

Taught live in a small group, remote over video, inside EkoFlow, our open source development environment.

• Four weeks, two evenings a week, live in a small group over video
• One booking API, designed and shipped by you: slots, conflicts, cancellation windows and the awkward parts nobody writes about
• Every line written test first, with no mock anywhere: the database, the clock and the outside world become Nullables you can command
• Your code reviewed by a person between sessions, the way a strong team reviews
• An architecture test that keeps the design honest after you stop looking
• The Solo plan on this platform, yours forever

The path

Each stage is built around doing the work, with a facilitator who asks rather than lectures. Read about how we teach

1. 1

   Week 1, Shape: what an API says before it does anything

   Resources rather than verbs, and the representation on the wire: what a booking is, in JSON, with times that carry their zone. Status codes that mean something, 201 with a Location, 204, and the difference between 404 and 403 when the answer itself would leak. Validation at the edge with Pydantic, and the first endpoint driven test first against the real application, no mock in sight.

2. 2

   Week 2, Seams: the database, the clock and the outside world

   A cancellation window is a rule about time, so time becomes something you command rather than wait for. Build Nullable infrastructure in Shore's sense: create_null with configurable responses and output tracking, for the store, the clock and the notifier. Your tests run in milliseconds against your own code, not against a mock of it.

3. 3

   Week 3, The hard parts: conflicts, repeats and errors

   Two people booking the last slot, and the same request arriving twice: conflict and idempotency, the two problems every real API meets and most tutorials skip. Errors as a contract rather than a stack trace, in the problem details shape. Authorisation that answers who may read whose booking, and the design decision hidden inside a 404.

4. 4

   Week 4, Keeping it honest: architecture, evolution and shipping

   An architecture test that forbids a route from touching the database, so the layering survives the next hurried change. Narrow integration tests against a real Postgres, pagination and filtering, and adding a field without breaking a client. Then you ship it, and read your own API back as a stranger would.