Reference and Selective Reading
You do not need to read the source books front-to-back for this module. Use the concept pages and practice pages first. Open these local chunks only when you need alternate exposition, more worked examples, or a deeper exercise lane.
Source Roles
| Source | Role | Why it is here |
|---|---|---|
| API Design Patterns (Geewax) | Primary teaching source | Default escalation for resource modeling, standard methods, custom methods, LRO, batch, pagination, filtering, versioning, and deprecation |
| Fundamentals of Software Architecture (Richards, Ford) | Selective support | APIs as architectural surfaces, event-driven style, monolithic-vs-distributed tradeoffs |
| Learning Domain-Driven Design (Khononov) | Selective support | Bounded contexts and integration patterns (Open Host Service, Published Language, Anticorruption Layer), event-driven architecture |
| Clean Architecture (Martin) | Peripheral | Boundary discipline between layers and services |
| Just Enough Software Architecture (Fairbanks) | Peripheral | Modeling vocabulary and architecture description |
Read Only If Stuck
Cluster 1: API as a Product
- Geewax: What are web APIs?
- Geewax: What are resource-oriented APIs?
- Geewax: Expressive and simple
- Geewax: Predictable
- Geewax: What are API design patterns?
- Geewax: Why are API design patterns important?
- Geewax: What makes a name good
- Geewax: Bad names case study
- Fundamentals: Defining software architecture
Cluster 2: HTTP / REST Resource Design
- Geewax: What is resource layout?
- Geewax: Types of relationships
- Geewax: Entity relationships
- Geewax: References vs inline, anti-patterns
- Geewax: Anti-patterns -- resources for everything / inline everything
- Geewax: Which methods, idempotence, GET
- Geewax: List
- Geewax: Create and update
- Geewax: Delete
- Geewax: Partial update motivation
- Geewax: Page size
- Geewax: Page tokens
- Geewax: Offsets-and-limits anti-pattern
- Geewax: Filtering structure
- Geewax: Filter syntax 1
- Geewax: Filter syntax 2
- Geewax: Filter syntax 3 and tradeoffs
Cluster 3: Beyond CRUD -- Actions, Events, Async Patterns
- Geewax: Custom methods motivation
- Geewax: Custom methods overview, side effects
- Geewax: Resources vs collections, tradeoffs
- Geewax: LRO motivation
- Geewax: LRO overview
- Geewax: LRO resolution
- Geewax: LRO error handling and monitoring
- Geewax: LRO canceling and exploring
- Geewax: Rerunnable jobs
- Geewax: Batch collective operations motivation
- Geewax: Batch atomicity
- Geewax: Batch get / create
- Geewax: Import / export
- Geewax: Import/export consistency
- Geewax: Request deduplication / idempotency
- Geewax: Exponential back-off
- Geewax: Retry-After and tradeoffs
Cluster 4: RPC, GraphQL, and Event-Driven APIs
- Fundamentals: Monolithic vs distributed architectures
- Fundamentals: Event-driven architecture style
- Learning DDD: Event-driven architecture
- Learning DDD: Types of events
- Learning DDD: Cooperation to conformist
- Learning DDD: Anticorruption layer
- Learning DDD: Model translation
Cluster 5: Versioning, Deprecation, Compatibility
- Geewax: What is compatibility?
- Geewax: Backward compatibility part 1
- Geewax: Backward compatibility part 2
- Geewax: Backward compatibility part 3 and implementation
- Geewax: Perpetual stability
- Geewax: Agile instability
- Geewax: Semantic versioning and tradeoffs
- Geewax: Granularity vs simplicity
- Geewax: Happiness vs ubiquity
- Geewax: Soft deletion motivation
- Geewax: Deleted designation
- Geewax: Expunging and effects
- Geewax: Soft delete across versions and tradeoffs
Optional Deep Dive
- Geewax: Request validation -- idempotent request validation
- Geewax: Resource revisions -- versioned resources in the wild
- Geewax: Revision identifiers
- Geewax: Request retrial -- retry-friendly API shapes
- Geewax: Request authentication
- Geewax: Polymorphism structure -- advanced resource modeling
- Geewax: Cross references
Concept-to-Source Map
| Primary concept | Best source if stuck | Why this source |
|---|---|---|
| What an API contract is and who it is for | Geewax: What are web APIs? | Opens the contract framing |
| The developer experience lens | Geewax: Expressive and simple | DX criteria made concrete |
| API governance | Geewax: Why are API design patterns important? | Consistency rationale |
| Resources and URL design | Geewax: What is resource layout? | Starting model |
| HTTP verbs, status codes, idempotency | Geewax: Which methods, idempotence, GET | Verb discipline |
| Pagination, filtering, sorting | Geewax: Page tokens | Cursor-first default |
| Custom actions on resources | Geewax: Custom methods motivation | Why CRUD does not fit |
| Long-running operations, webhooks, async | Geewax: LRO overview | Core async contract |
| Batch and bulk patterns | Geewax: Batch atomicity | Hardest batch decision |
| RPC styles (gRPC, JSON-RPC) | Fundamentals: Monolithic vs distributed | Where RPC fits in topology |
| GraphQL | Fundamentals: Event-driven architecture style | Contrast with schema-first |
| AsyncAPI and event-driven contracts | Learning DDD: Types of events | Notification vs state-carried |
| Backward and forward compatibility | Geewax: Backward compatibility part 1 | Concrete rules begin here |
| Versioning strategies | Geewax: Semantic versioning and tradeoffs | Middle ground versioning |
| Deprecation and sunset discipline | Geewax: Soft delete across versions and tradeoffs | Live-API deprecation pragmatics |
External Community References
- Google Cloud API Design Guide
- Google AIPs -- API Improvement Proposals
- Microsoft REST API Guidelines
- Stoplight API Design Guide
- OpenAPI Specification
- JSON:API Specification
- RFC 7807 -- Problem Details for HTTP APIs
- RFC 8594 -- Sunset HTTP Header
- RFC 9745 -- Deprecation HTTP Header
- gRPC documentation
- JSON-RPC 2.0 Specification
- GraphQL Introduction
- GraphQL Best Practices
- Principled GraphQL (Apollo)
- AsyncAPI Specification
- CloudEvents Specification
- Stripe API Reference -- live example of date-header versioning done well