13. It has a @twitter account
Communicates feature updates, new versions, etc.
Exposes itself in API directories
Provides health / uptime / downtime info
15. It’s beautifully described
Generous and easily navigable documentation
Code examples for “relevant” languages
Metadata for code generation and testing
19. It has a sandbox for experiments
Limited functionality or content
Simulations of errors and out-of-bounds situations
No limits on usages – doesn’t consume quota
21. It has out-of-the-box clients
Lowers barrier of entry
Adapts API to client paradigms
Hides complexity related to authentication, parsing, etc.
23. It knows and serves its user
Uses the right technologies for the domain
Respects security and authentication requirements
Adopts common nomenclature and naming
25. It’s aware of its own constraints
Continuously evaluates its own performance
Monitors third-party APIs and dependencies
Handles unexpected events gracefully
27. It’s prepared for (r)evolution
Versioned from day one in line with best practices
Communicates and implements a versioning strategy
Handles “old” clients gracefully
29. It follows the 3:30:3 rule
3 seconds to understand what the API does
30 seconds to find the endpoint
3 minutes to be up and running
Thanks to Ori Pekelman!
30. I hope you’ve enjoyed this presentation
and that you are able to apply some of
these habits to your own APIs.
31. And now that you know how to make
your own APIs effective…
32. Take a few minutes to learn how to use
other people’s APIs safely…
