A framework is a group of classes, interfaces and other pre-compiled code upon which or by the use of which applications can be built.
The API is the public face of a framework. A well designed framework only exposes those classes, interfaces, etc that are needed to use the framework. Code that supports the operation of the framework but that is not necessary to users of the framework is kept internal to the framework’s assemblies/dlls. This keeps the public face of the framework small and encourages a “pit of success,” or the quality of a framework which makes it simple to do the right thing.
(I provide an example from the .NET world)
The SqlConnection class is used to connect to a Sql Server instance. Its public API is pretty simple:
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open();
// Do work here; connection closed on following line.
}
However, this class depends on around 200 methods within the System.Data framework (in this case, an assembly), 3/4 of which are internal and not part of the public API of System.Data. Because the framework’s API is kept simple, it becomes easy to use SqlConnection properly. If the user was required to deal with SqlConnectionFactory, SqlDebugContext, DbConnectionPoolGroup or any of the other internal classes required by the SqlConnection class, it would become exponentially more difficult to use SqlConnection properly. Because the API only exposes a small percentage of the framework, it is easier to create and use a connection.