This is a message from a management blog, but I think the arguement is also apply API design. In fact, I think most critical difference of good and bad API is knowing which small detail is important and which is not - http://www.goodproductmanager.com/2007/11/08/sweat-the-small-stuff/

Design tips:
http://www.artima.com/weblogs/viewpost.jsp?thread=142428
http://openide.netbeans.org/tutorial/api-design.html
http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3258158706
http://today.java.net/pub/a/today/2006/08/24/five-habits-of-highly-profitable-developers.html
http://www.infoq.com/news/2007/08/why-api-design-matters
http://www.infoq.com/presentations/effective-api-design
http://neuroning.com/2006/11/19/on-api-design-guidelines

About Compatibility issues
http://wiki.eclipse.org/Evolving_Java-based_APIs

A blog of using interfaces-vs-abstract-classes
http://hoskinator.blogspot.com/2006/04/interfaces-vs-abstract-classes.html

XOM design overview - http://www.xom.nu/designprinciples.xhtml#d0e309

You need to identify the business value but not pick any tools/design just because it is cool - http://myarch.com/what-is-good-soa

A lot of links here - http://kasparov.skife.org/blog-live/src/api-design-refs.writeback http://discuss.joelonsoftware.com/default.asp?design.4.527465

An introduction of good OSS project to study their source - http://techkriti.wordpress.com/2007/06/28/learning-from-the-source/

CCCCDPIPE - http://blog.objectmentor.com/articles/2007/08/02/which-came-first

Discussion of why getting feedback quick is important - http://blog.objectmentor.com/articles/2007/11/13/you-dont-know-what-you-dont-know-until-you-take-the-next-step

Someone saying that routines is the greatest invention in CS, I agree - http://www.codinghorror.com/blog/archives/001129.html

New way of modeling system then layering,  The Onion Architecture - http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

SOLID - http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx http://dotnet.dzone.com/news/solid-software-works <-- very good picture! http://www.blackwasp.co.uk/SOLIDPrinciples.aspx https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/

Idempotent, Orthogonality, Immutability - http://www.codinghorror.com/blog/archives/001244.html

Some example of how to driven good API - http://jdegoes.squarespace.com/journal/2009/5/11/good-api-design-part-3.html

It's not enough to write tests for an API you develop, you have to write unit tests for code that uses your API. When you do, you learn first-hand the hurdles that your users will have to overcome when they try to test their code independently. http://butunclebob.com/ArticleS.MichaelFeathers.TheGoldenRuleOfApiDesign

Active interface vs. Passive interface, for me this is another way to under "Tell, don't ask" - http://code-o-matic.blogspot.com/2011/01/note-on-api-design-call-stack-as-source.html

The Principles of Good Programming - http://www.artima.com/weblogs/viewpost.jsp?thread=331531

http://net.tutsplus.com/tutorials/tools-and-tips/3-key-software-principles-you-must-understand/

Difference choice of how API evolute with change - http://blog.jooq.org/2013/02/01/defensive-api-evolution-with-java-interfaces/

JUnit's evolving structure. - http://edmundkirwan.com/general/junit.html

API performance contract - http://queue.acm.org/detail.cfm?ref=rss&id=2576968

Consistent naming conventions
Standard terminology
Uniform error responses
Attention to detail (that’s the love part for APIs)
REST APIs that work with only 2 resources and use 4 HTTP verbs (oh, there is so much more to talk about here…)
Avoid API design by way of method-driven approach – that leads you down a slippery slope
- See more at: http://blogs.ancestry.com/techroots/apis-are-like-parenting/#sthash.Ux1LHMNU.dpuf

http://blog.jooq.org/2015/05/21/do-not-make-this-mistake-when-developing-an-spi/

Guideline for webapi - https://cloud.google.com/apis/design/

Good naming is part of design. It sets expectations and communicates a model, showing how something should be understood and used. If you mean to tell the reader getMillisSince1970, don’t say getTime. Specific names inspire you to consider alternatives, to question whether you’re capturing the right abstraction in the right way. It’s not just labeling and it’s not just java.util.Date: This is about the code you write and the code you use. - https://medium.com/97-things/name-the-date-c82bafdc4c44