I actually think this is a really good question because developing an API is a whole different beast than developing something like a service layer, business layer, etc.

There are different strategies for it, and it really comes down to being very disciplined with object structure, and very consistent with your method signatures, also providing good documentation (APIs are meant to be consumed by others, usually). Also, the API should really focus on ease of use for the consumer. If the consumer needs to know something special about the API (for example, having to run some sort of "init" routine before using a feature) then that's a bad sign.

Also, as opposed to something like a business tier where everything is super modular and I tend to have a bunch of different namespaces for cleaner separation, I like to design my APIs so they are more coarse grained and act more like a facade into the API's functionality, therefor I typically will have more objects under a particular namespace, rather than forcing the user to navigate through a bunch of namespaces to find things. I really try to limit any sort of "special knowledge" about the system.

One great API in my opinion is the eBay .NET SDK. It's a great example of a nice consistent API. Very consistent naming, nice shallow inheritance hierarchies, easy to find objects because they aren't cordoned off into a bunch of different namespaces, easy to use, and lots of documentation online. Even if you don't use it, I recommend checking it out and looking through it just to see the design.

But this is a very broad topic so I'll point you to this book, which should get you off to a good start (and it's only like 160 pages!).