API Team Mantra
Do your APIs solve your problems or create them? What is 200 OK and when should it be used? Let’s say up front what we’d say at the end.
Is the following correct? We say no: Returning 200 OK for a response that contains an error goes against API design standards. This doesn’t only affect API design; it can trigger many issues in system architecture.
For example, monitoring products usually treat 2xx responses as success. If 200 OK doesn’t actually mean success, monitoring must look at message content as well as status codes, which leads to potential issues and observability problems.
Remember: Especially when you share data with external partners via APIs, APIs are not just technical interfaces — they are your products, and developers are your customers.
A good API Program Manager / Product Manager / Developer Advocate lives by this mantra:
"APIs should help you solve your problems. APIs should not be your problem." — David Biesack
APIs are the bridges through which software systems communicate, share data, and work together. A well-designed API makes interaction easy; a poorly designed one creates complexity and trouble. APIs are your products; developers are your customers.
Core Principles for the API Team
"We design our API from the developer’s perspective." That may sound simple, but in practice it’s hard; many teams say it but don’t fully live it. Here are the core principles in summary.
1. Developer experience (DX) comes first
Design your APIs from the developer’s point of view. They are your customers; you must deliver a good customer experience.
Ask yourself: How easy is your API to understand? Is the documentation clear and helpful? Is usage intuitive?
Common pitfall: Complex authentication/authorization. Even standards like OpenID Connect or OAuth2 can be tough for developers without the right libraries.
Practical solution: Offer quick-start guides, simple auth options, and sandbox environments; provide step-by-step visual guides for the auth flow.
2. Simplicity and clarity are key
Complex APIs waste time, increase the chance of errors, and frustrate developers. A good API should do the most with the least effort.
Common pitfall: Exposing database schemas or internal system structures as-is.
Practical example: Use real booleans instead of "Y"/"N"; use meaningful strings or enums instead of opaque integer codes.
Strong solution: Use JSON Schema to define fields correctly and state required fields and formats clearly. Expose a clean model that matches your API’s purpose.
3. Consistency is essential
Naming conventions, response formats, parameter structures, and error messages should be standard and predictable. Inconsistency erodes trust.
Common pitfall: Ignoring HTTP semantics: returning 200 for errors instead of 4xx/5xx; using 200 instead of 201 Created for POST; GET that isn’t idempotent and safe; not using standard headers like Location and Retry-After.
Strong solution: Create an API Style Guide; use Arnaud Lauret’s “five dimensions of API consistency” as a reference and follow HTTP semantics.
4. Reliability and performance are non‑negotiable
An API must respond quickly and run reliably. A slow or constantly failing API drives developers to other solutions.
Common pitfall: Not thinking about error handling from the start.
Strong solution: Plan how you’ll handle errors; use standard error formats like application/problem+json; provide clear, actionable messages for each error; identify and optimize bottlenecks early; run load tests and plan for capacity.
5. Design with the future in mind (evolution)
APIs change over time. The design should be extensible, preserve backward compatibility, and adapt to future changes.
Common pitfall: Designing the API so it can’t evolve, or assuming that changing the version in the URL (/v1/ → /v2/) is enough.
Strong solution: Use API Design and Documentation Review (ADDR) processes; model use cases in advance; use versioning only for major changes; make small changes in a backward-compatible way; roll out changes gradually.
6. Open communication and transparency
Planned changes, new releases, and deprecations should be announced proactively and clearly; feedback channels should be open.
Practical solution: Maintain a detailed changelog; announce upcoming changes in advance; allow a transition period for deprecated features; provide forums or community channels; run regular webinars and training.
What successful APIs have in common
- They state their purpose clearly
- They rest on a clear conceptual model
- They serve user needs instead of reflecting internal system structure
- They follow standards, especially HTTP semantics
- They behave in ways developers can predict
- They handle error cases effectively
- Their evolution is planned from the start
Common API design mistakes and fixes
| Mistake | Result | Fix |
|---|---|---|
| Returning 200 OK for errors | Observability issues | Use appropriate HTTP status codes (4xx, 5xx) |
| Complex authentication | Integration difficulties | Offer simple, standard auth mechanisms |
| Inconsistent naming | Inconsistent codebases | Create an API Style Guide and stick to it |
| Mirroring database structure | Unnecessary complexity | Design clean models aligned with business goals |
| No evolution plan | Version chaos | Design for extensibility from the start |
Conclusion: Living the mantra
APIs are not just pieces of code; they are strategic business assets. A successful API program puts developers at the center, makes their job easier, and produces simple, consistent, reliable, and forward-looking designs.
By embracing the mantra “APIs should solve your problems, not be your problem” and applying the principles above, you can build APIs that developers love and that serve your business goals.
Most important steps:
- Follow HTTP standards
- Return meaningful error codes
- Continuously improve developer experience