1. API Design Tutorial
2. API Design: Lots of Upfront Design
3. API Design: Keep it Small and Focused
4. API Design: Don't Expose More than Necessary
5. API Design: Provide Sensible Defaults
6. API Design: Optional Abstractions
7. API Design: Central Point of Access
8. API Design: Don't Force the User to Assemble Components
9. API Design: Avoid External Dependencies
10. API Design: Avoid Logging in your APIs
11. API Design: Design for Testing
12. API Design: Design for Easy Configuration

When you are implementing an API it may sometimes be a temptation to use external libraries, for instance the Apache Commons or Log4J, in your API.

Don't do it, unless there is absolutely no way around!

External dependencies make your API code swell quickly. Just look at Spring, or Apache Axis for proof of that. This means larger code bases, for the end user of the API, and thus sometimes slower build time. Slow build time can be really annoying during development, and a real time robber and productivity killer.

Additionally, the version of the external dependency you are using may clash with the version used in other API's, or in the final application your API is being used in.

External dependencies are, in my opinion, primarily for use in the final applications, not in API's and frameworks. Not unless you know for sure that the final application will also use the same version of that dependency. Or, if that dependency can be swapped for a different version without problems.

My Java web framework Butterfly Web UI has a single external dependency: Butterfly DI Container. But, Butterfly Web UI uses very little functionality of Butterfly Container, so no matter what version of Butterfly Container you end up using in your web application, it will not cause problems. In addition, I control both of these API's, so it is much easier to steer clear of dependency problems.