APIDesign
The shape of an API contract itself — independent of transport/protocol (see CommunicationPatterns/Protocols for that angle).
Why we need this / what value this brings
A consistent, well-versioned API contract is what lets frontend and backend (and future third parties) evolve independently without breaking each other.
When to use this
Whenever you're adding a new endpoint or changing an existing one's shape — decide the convention once, apply it everywhere.
How to use or implement this
Write the schema (Zod/Pydantic) first, generate or hand-write the contract doc, and review it the same way you'd review code.
Subtopics
Research questions
- For Localz's booking/marketplace API: REST, or is there a case for GraphQL on the storefront read side?
- What's the versioning strategy before the first breaking change actually happens?
Empty folder — drop notes, links, and findings here as you research.