An API, or an Application Programming Interface, is the way your application, or one of its components, interacts with any other code using it.

That sentence implies an assumption that is one of the fundamental aspects of creating a well-designed application: when using components, you should use their APIs and not muck around with internals or include pages directly. And conversely, when writing an API, you must expose enough functionality that users can make full use of the API without having to muck with internals.

Here is an example of an API for a Browser detection class: http://dev.horde.org/api/framework/Horde_Browser/Browser.html. It includes methods to do the things you'd expect of such a class, along with accessors for all of the member variables that you would want to access. Why is this important? Why go through the overhead of calling a function instead of just accessing things directly? Well, we recently changed some of the internal data structures/member variables of the class. And we had a few pieces of code that had been accessing member variables directly. Guess what: they all broke. Now that we have all of the appropriate accessors and are using them everywhere, even if we change the internal variables again, that won't happen.

The other lesson to draw from this is that when someone changes how something works, they'll almost always fix anything that that change breaks in the same file - but tracking down any affected code outside of that file usually only happens bit by bit as people find breaks. So as much as you can insure that changes won't affect anything other than their immediate class - i.e., don't change the API, and stick to the API - things will break that much less.