An internal API is an interface exposed for use within an organization’s systems or network. It may serve one team, several teams, or applications across the organization, and can still be exposed over the internet. section 1.1.4 section 1.8
Internal APIs deserve deliberate design because they affect development, security, infrastructure efficiency, costs, and end-user experience. Designing them also builds practice for partner and public APIs. section 1.3.1 section 1.8
One organization, several API boundaries
SOCNET uses private Backend and Friends APIs internally, offers a Search API to selected partners, and consumes a public Face Detection API. These boundaries show why teams should clarify whether “internal,” “external,” “private,” or “public” describes network location, audience, or openness. section 1.1.4
Design choices for internal APIs include:
- Treat every new internal API as a design task rather than an implementation afterthought. section 1.3.1
- Build internal APIs with future consumers in mind, while recognizing that a polished partner or public façade may be safer than an instant transition. section 1.3.1
Figure 1.4 The terms internal, external, private, partner, and public API may need to be disambiguated so everyone involved understands each other.
Use the terminology map to distinguish internal, external, private, partner, and public API boundaries. section 1.1.4
