An API model represents data crossing an application programming interface. It acts as a boundary type between networking code and business logic, rather than as a domain or database type. API models are usually value types with no attached logic; data arriving from outside is transformed into justified domain values before business operations use it. section 14.1.1 section 14.2.4
Use an API model to keep external communication separate from internal behavior:
- Define request and response shapes specifically for communication, instead of exposing domain types directly. section 14.1.1
- Keep API models mostly logic-free and place them only between networking code and business logic. section 14.1.1
- Validate incoming API values before converting them into domain values, returning an error for invalid requests. section 14.2.4
- Prefer focused endpoint models over one universal type filled with optional or undefined fields, while watching for needless duplication. section 14.1.1
Asteroid request model
An HTTP schema can accept an AsteroidTemplate containing size, mass, azimuth, and altitude, then return an AsteroidId. The template describes the network payload; it does not replace the protected domain model.
Validation at the boundary
An AstroObjectTemplate may contain an optional name plus objectClass and code. A handler rejects an empty name, object class, or code with a 400 Bad Request before calling business logic.
