One of the most interesting things I ever saw about API design was a presentation by Casey Muratori called "Designing and Evaluating Reusable Components".
It's the first time I saw anyone acknowledge this profound insight: sometimes, writing a practically useful API entirely at the same level of abstraction simply isn't possible.
One library I've found very useful to study is libcurl -- it has a very elegant degradation system. Easy things start out easy, and when the user chooses to handle more complexity she can switch to a lower-level set of calls.
There is surprisingly little written about good API design. Maybe it's because the important things to say have already been said, but I have my doubts that that is the reason.
I suspect it's partly because of the difficulty involved in measuring the quality of a given API's design. How do you separate the success resulting from the usefulness or popularity of the technology from the design of the API?
That was the first thing I though on starting to read this. How do they know they've actually got it right? Feedback from users?
This is an excellent little PDF that was very useful to me when I put together a recent talk titled "API Design Matters". It's amazing how a bit of energy spent focusing on an API's design can improve so many aspects of both using and developing said API.
It's the first time I saw anyone acknowledge this profound insight: sometimes, writing a practically useful API entirely at the same level of abstraction simply isn't possible.
Looks like it's available here, now:
http://mollyrocket.com/9438