An API is a defined software interface through which programs or users access capabilities or data provided by a system. In platform engineering, every capability should expose an API so teams can consume it through self-service rather than depending on manual coordination. section 1.3.3
Treat APIs as an architectural and product boundary:
- Design the service interface first, then add user interfaces or other developer tools on top. section 1.3.3
- Use the API to create clear working boundaries between platform teams and support independent domain-focused development. section 1.3.3 section 2.1.3
- Preserve the ability to evolve the implementation as technologies, customer expectations, and observed inefficiencies change. section 1.3.3
- Make platform APIs the foundation for integration and extensibility, while measuring whether consumers receive a reliable, low-friction experience. section 9.4 section 2.1.3
Capability delivered as a service interface
A platform team starts with an API for a capability, validates its value through realistic implementation and alpha-user feedback, and then builds a portal or other interface on top. This keeps the capability reusable while testing whether it reduces developer friction. section 1.3.3 section 2.4
Figure 1.5 Software defined is placed in the middle because it is a core attribute of everything the platform engineer delivers. The rest of the principles share a connection because they continuously evolve, and decisions made in applying these surrounding principles can affect the requirements of the others.
Use the principle map to relate API-first self-service to software-defined delivery, evolutionary architecture, and metrics-driven success. section 1.3.3
