An API is a defined interface through which software components request functionality or exchange data. In an ML system, it can expose a model to users or other components while hiding implementation details. section 13.1.1
Treat API design as an integration concern, not a one-time handoff. Favor simplicity and predictability, then evolve the interface without unnecessarily breaking clients. section 13.6
Practical API design for ML systems includes:
- Separate an external API from an internal API. Keep the external surface compatible and simpler, while allowing the internal implementation to change. section 13.1.1
- Separate ML and input/output components when possible. A stateless, idempotent ML service can be scaled independently and replaced gradually. section 13.1.1
- Provide a client library to lower the entry barrier and centralize recommended retries, timeouts, and similar usage practices. section 13.1.1
- Use feature toggles or equivalent controls, and maintain a fallback for cases where the primary solution fails or becomes unavailable. section 13.1.1 section 13.6
Using an API as a baseline
A team can compare a custom image or language solution with a zero-shot or few-shot service such as Amazon Rekognition, Google Cloud Vision AI, or a GPT-family API. The comparison supplies a practical baseline before committing to custom training. section 8.4
Figure 13.2 Layered API structure is simpler to maintain, test, and develop.
Use the layered API diagram to compare the external interface with the internal implementation and see why the separation supports maintenance, testing, and development. section 13.1.1
