Go Idiomatic API Design
Design from the caller's code inward. Prefer the smallest coherent public
surface that preserves invariants and can evolve without needless interfaces.
Core Workflow
- Identify callers, supported operations, and compatibility constraints.
- Sketch realistic call sites before choosing exported names or types.
- Keep packages cohesive and names clear without package-name stutter.
- Prefer concrete provider APIs; define narrow interfaces at consumers.
- Decide zero-value, mutation, copying, concurrency, and error contracts.
- Review embedding, receiver method sets, typed nils, generics, and option conflicts.
- Integrate standard interfaces only when their semantics truly match.
- Prove the public surface with external tests and executable examples.
- Review the change for accidental compatibility commitments.
Read Next
| Task |
Load |
| Design or evolve an API |
guidelines.md, workflows/review-public-api.md |
| Choose types, fields, methods, or interfaces |
references/api-design/rules.md |
| Understand compatibility and method sets |
references/api-design/knowledge.md |
| Review concrete patterns |
references/api-design/examples.md |
Guardrails
- Do not export a field merely to avoid writing behavior.
- Do not define a provider-wide interface as a mirror of its methods.
- Do not accept an interface before a real consumer requires substitution.
- Do not use a standard interface when its conventional semantics are surprising.
- Do not claim conformance assertions prove behavior.
- Do not embed a public type unless every promoted behavior is intentional.
- Do not return a typed nil pointer through an interface success path.
- Check the module's Go language version before giving version-sensitive advice.
Source Notes
Guidance is transformed and paraphrased from Inanc Gumus, Go by Example:
Programmer's Guide to Idiomatic and Testable Programs (Manning, 2025),
especially Chapters 1, 2, 5, 9, and 10. Examples are original.
Embedding, receivers, generics, functional options, and typed-nil guidance also
incorporates transformed material from Teiva Harsanyi, 100 Go Mistakes and
How to Avoid Them (Manning, 2022), Chapters 2 and 6.
Book: https://www.manning.com/books/go-by-example
Current language and documentation contracts should be verified against
https://go.dev/ref/spec, https://go.dev/doc/comment, and the module's pinned Go
version.
1---2name: go-idiomatic-api-design3description: Design and review stable, idiomatic Go package APIs covering naming, exported declarations, embedding, receivers, typed-nil interfaces, generics, functional options, method sets, errors, wire contracts, compatibility, and examples. Use when creating a reusable Go package, reviewing its public surface, evolving an exported API, or choosing concrete types, functions, methods, fields, interfaces, or type parameters.4license: MIT5---67# Go Idiomatic API Design89Design from the caller's code inward. Prefer the smallest coherent public10surface that preserves invariants and can evolve without needless interfaces.1112## Core Workflow13141. Identify callers, supported operations, and compatibility constraints.152. Sketch realistic call sites before choosing exported names or types.163. Keep packages cohesive and names clear without package-name stutter.174. Prefer concrete provider APIs; define narrow interfaces at consumers.185. Decide zero-value, mutation, copying, concurrency, and error contracts.196. Review embedding, receiver method sets, typed nils, generics, and option conflicts.207. Integrate standard interfaces only when their semantics truly match.218. Prove the public surface with external tests and executable examples.229. Review the change for accidental compatibility commitments.2324## Read Next2526| Task | Load |27|---|---|28| Design or evolve an API | `guidelines.md`, `workflows/review-public-api.md` |29| Choose types, fields, methods, or interfaces | `references/api-design/rules.md` |30| Understand compatibility and method sets | `references/api-design/knowledge.md` |31| Review concrete patterns | `references/api-design/examples.md` |3233## Guardrails3435- Do not export a field merely to avoid writing behavior.36- Do not define a provider-wide interface as a mirror of its methods.37- Do not accept an interface before a real consumer requires substitution.38- Do not use a standard interface when its conventional semantics are surprising.39- Do not claim conformance assertions prove behavior.40- Do not embed a public type unless every promoted behavior is intentional.41- Do not return a typed nil pointer through an interface success path.42- Check the module's Go language version before giving version-sensitive advice.4344## Source Notes4546Guidance is transformed and paraphrased from Inanc Gumus, *Go by Example:47Programmer's Guide to Idiomatic and Testable Programs* (Manning, 2025),48especially Chapters 1, 2, 5, 9, and 10. Examples are original.4950Embedding, receivers, generics, functional options, and typed-nil guidance also51incorporates transformed material from Teiva Harsanyi, *100 Go Mistakes and52How to Avoid Them* (Manning, 2022), Chapters 2 and 6.5354Book: https://www.manning.com/books/go-by-example5556Current language and documentation contracts should be verified against57https://go.dev/ref/spec, https://go.dev/doc/comment, and the module's pinned Go58version.
LVTD-LLC