Good API design is such a broad topic (because there are a wealth of programming languages and ways you can communicate with systems and code) that you're not g

Good API design is such a broad topic (because there are a wealth of programming languages and ways you can communicate with systems and code) that you're not going to find one that probably suits you without being more specific. Lets assume you are talking about a class API (like a C, C++, Java API for example) and are just either defining a library or an interface into your application from code that is loaded from the application's runtime environment. In that case I could say what you might look into first would be good OO design and head you off into "Design Patterns" as a classic (there is also an online Java equivalent of that book which I think is "Java Design Patterns"). But then you'll spend your years as a junior and mid-tier developer obsessed with designs and which design to best use. Having the right classes that "make sense" to a developer is wise, but spending too much time with patterns isn't. What I'd suggest is to just look at a number of APIs similar to what you want and try to create something similar. Basically you want something intuitive, so design something similar to what developers are used to. Consider what needs to be public in the API. If it isn't providing something obviously and directly related, it should be in a different library. As for deprecation of methods over time, this used to be something that was done differently than now. Used to be that you would be concerned about people continuing to use your API with older code. These days a number of groups developing (especially for applications) will force people to change and update by making their API less backwards compatible (not many do this, but enough to make it hurt- and it sucks). Good luck!