Organizations who are paying attention already know they need to have an open web API, and many already have under development or in the wild. Make sure you haven’t been caught by the pitfalls of many early API releases.
Multiple points of failure
- Back-end systems: db servers/caches, hardware failures, etc.
- Interconnections: router failures, bad cables, etc.
- External Dependencies: fail whales, random cloud latency, etc.
The 5 tips
- Test it all
- Unit test are not enough, they are just the beginning.
- Test what users experience. Perform end-to-end black box tests.
- Replay your access logs. Very accurate.
- Validate return payloads. A stack trace is not valid XML.
- Plan for future versions
- Versions are not sexy/semantic (but do it anyway).
- Announce versions often.
- Embrace standards
- APIs are better when predictable.
- Standard approaches mean tools.
- Avoid uncomfortable migrations. No one wants an OAuthpocalypse.
- Monitor everything & be honest
- Trends are your friend.
- Users are not your early-warning ops team.
- Be open and honest, or your users will tweet that your API sucks!
- Fail well
- Well-formed errors win friends and makes users more tolerant to failure.
- Make monitoring easy.
- Don’t punish everyone. Determine who gets hurt most by failures.
Watch the video here: Understanding API Activity by Clay Loveless