Recently at
Songbird I've been working on
some guidelines to help us build better APIs. One of the most exciting
things we're hoping to offer users and developers are APIs that give
them access to their music and the ability to extend their and others'
music players. Getting these APIs right can be hard and we think we can
do better, so we came up with some ideas and we're trying to get some
wider feedback.
Our guidelines come in two parts - general rules that apply across the
board, and platform-specific conventions depending on what the specific
APIs are based on (Mozilla Extension API vs Web Page JavaScript). Here's
our general guidelines:
- APIs should be orthogonal and symmetrical
-
Method naming, argument ordering and error handling should be
consistent
-
Code that uses the API should read like prose. Words should not be
abbreviated. It should be easy to understand code that uses the API
without having read the documentation
-
The API should follow the terminology, conventions and idioms of the
platform that is is built on
-
Use cases and target developers should be taken into consideration
when the API is being designed and documented
-
Developers should be able to continue to use the tools and libraries
that they are familiar with when using the API. Their previous
development experience should help them learn and understand the API
quickly
These are based on research I did - I distilled half a dozen other
peoples' ideas about good API design into ones that we could easily apply
to our own work.
The full document fleshes these out a little more, with examples and
then goes into platform specific patterns to follow.
If you're interested,
read it
and please send your comments.