I require that every event an API emits is enumerated in a published catalog of event types, each with a stable name, a described payload, and a clear meaning, so consumers know exactly what can happen and can subscribe to it deliberately. Events that only exist implicitly in the code are impossible to discover, impossible to govern, and impossible to reuse across teams. I push for this at design time and make it discoverable because the value of an event-driven system is only realized when the events themselves are a first-class, browsable part of the contract. Every API that produces events must maintain its event type catalog as a living artifact, not an afterthought.
Event Types Cataloged
Strategies
APIs Use the Right Protocol for the Job
I want us to stop treating REST as the answer to every problem and instead pick the protocol that actually fits the job in front of us. When the interaction is event-driven we describe it with Asyn...
Experiences
Integration
Integrating digital resources and capabilities into other systems using HTTP APIs is commonplace in any enterprise. However, the experience, skills, time, and cost required for successful integrati...
Discovery
The average enterprise maintains approximately 0.5 APIs per employee, making it a constant challenge to track the growing inventory of HTTP APIs being produced and consumed. Enterprises often addre...
Lifecycle
design_services Design Design
Design is where the human experience of an API is won or lost. I work design-first, shaping the paths, schema, errors, and naming in the contract before development begins, so that consistency is b...
travel_explore Discovery Production
Discovery is how APIs get found and reused instead of rebuilt. APIs.json, catalogs, and search make the APIs I operate visible to the people who need them. Good discovery is what turns a pile of AP...
