Una respuesta de la lista de correo de Debian, firmada por Colin Watson en febrero de 2004, aclara de forma didáctica la distinción entre una API (Application Programming Interface) y una ABI (Application Binary Interface), dos conceptos que suelen confundirse porque ambos describen cómo los desarrolladores interactúan con una biblioteca.
La API es la interfaz a nivel de código fuente: las declaraciones de funciones, junto con la documentación sobre su comportamiento, argumentos y valores de retorno. Por ejemplo, las funciones fopen, fdopen y freopen del encabezado constituyen una API. La ABI, en cambio, es la interfaz vista por el código ya compilado: depende de detalles como el orden de los bytes en un entero, el tamaño de un puntero, la disposición de los argumentos en la pila al invocar una función y, en casos más complejos, la forma en que se organizan los elementos dentro de una estructura.
El texto aborda también las implicaciones de cambiar cada tipo de interfaz. Añadir funciones o elementos al final de una estructura suele ser compatible hacia atrás. Hay situaciones en las que la ABI se rompe sin que lo haga la API, por ejemplo cuando una función se transforma en una macro que envuelve código nuevo: los binarios antiguos dejan de funcionar, pero el código fuente sigue compilando. Cuando la ABI cambia de forma incompatible, el soname de la biblioteca (como libc.so.6) debe modificarse; si el cambio es compatible, en Debian se actualiza el archivo shlibs correspondiente para reflejar el momento en que se introdujeron las nuevas interfaces binarias. Romper la API, por el contrario, obliga a los desarrolladores a modificar el código fuente de sus programas, algo que ocurre en ocasiones con bibliotecas importantes de proyectos como GNOME y KDE.