The core of API design is the contract between a module and its callers: what is exposed, what is hidden, and how much the caller must know to use it correctly. Four sources touch this from different angles, all arriving at the same conclusion: leaky, wide, or unvalidated interfaces create problems at scale.

Zod-based response validation addresses the external API surface: when a backend response deviates from the expected shape, runtime errors surface in production rather than at dev time. Wrapping Angular HTTP calls with a custom RxJS operator that validates against a Zod schema catches those mismatches early, treating the API contract as something to enforce rather than assume.

Conductor illustrates what a well-designed API can replace: decades of qbXML and SOAP complexity collapsed into a typed Python, Node.js, and REST interface covering 130+ QuickBooks objects. The abstraction works because it hides implementation detail completely, exposing only the objects callers actually need.

The component-level analogue appears in Angular component composition: components with dozens of inputs are effectively wide APIs. Each input is a coupling point. Moving concerns into directives and sub-components narrows the interface and keeps each unit’s contract legible.

AI Likes Deep Modules makes this explicit: deep modules, interfaces that hide complexity behind a small surface, are easier for LLMs to reason about than shallow ones that leak implementation detail across layers. The argument applies equally to human callers. A narrow interface forces the designer to decide what matters; a wide one defers that decision to every consumer.