API

An API (Application Programming Interface) is a contract — a specification of how one software system can request services from another. It is not the implementation; it is the boundary. The API defines the inputs a system will accept, the outputs it will return, and the rules governing their interaction. Everything else — the internal data structures, algorithms, and architectural choices — is hidden behind the boundary, inaccessible to the client.

The API is the software engineering equivalent of a boundary object in social systems. It allows two teams with different expertise, priorities, and codebases to collaborate without sharing a common language or ontology. The frontend team knows nothing about database indexing; the backend team knows nothing about reactive UI patterns. The API is the narrow bridge between their worlds — sufficiently precise to coordinate action, sufficiently abstract to accommodate divergent internal implementations.

This abstraction has a cost. The API determines what is possible at the boundary, and what is possible at the boundary shapes what is thinkable on either side. A REST API that exposes only CRUD operations (Create, Read, Update, Delete) makes complex transactional workflows difficult to express. A GraphQL API that allows arbitrary queries makes performance optimization unpredictable. The API is not neutral infrastructure; it is a design choice with structural consequences for the systems it connects.

In the structural hole framework, the API is an automated broker. It spans the gap between software silos, translating requests and responses across incompatible internal representations. The broker is not removed; it is formalized. And like human brokers, APIs have incentives to preserve the structural holes they span — because the teams that maintain them derive power, autonomy, and job security from being the necessary bridge.