How to Design a Good API and Why It Matters.¶
Bloch, J. (2006). How to Design a Good API and Why It Matters. ACM, 506-507.
Cited by¶
3 citations across 3 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Progressive Disclosure
- Software architecture and APIs. High-level facade calls that delegate to lower-level primitives reachable only when needed; sensible defaults overlaid on a rich configuration surface.
This sourceArgues for facade-level calls over rich configuration with sensible defaults, the API form of layered presentation.
- Software architecture and APIs. High-level facade calls that delegate to lower-level primitives reachable only when needed; sensible defaults overlaid on a rich configuration surface.
- Rule of Least Power (Minimum Sufficient Capability)
- In API and protocol design, it appears as exposing the smallest interface that meets the use case, since every extra method is a future compatibility constraint and a future attack surface.
This sourceAdvocates the smallest sufficient public interface — "when in doubt, leave it out" and minimize accessibility — because anything exposed becomes a permanent compatibility constraint that can never be removed.
- In API and protocol design, it appears as exposing the smallest interface that meets the use case, since every extra method is a future compatibility constraint and a future attack surface.
- Signifier
- API design and software ergonomics. Method names, type signatures, auto-complete, tooltips, null-safety operators, and deprecation warnings — the signifier face of an API publishes which calls are available and how to compose them.
This sourceArgues that names, method signatures, and self-documenting interfaces make an API's available calls discoverable ('if you get an API right, code reads like prose') — the signifier face of software ergonomics.
- API design and software ergonomics. Method names, type signatures, auto-complete, tooltips, null-safety operators, and deprecation warnings — the signifier face of an API publishes which calls are available and how to compose them.
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Not recorded. Neither this nor any other of the 3 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:240a05da01ff · see in the full table