Canonical contract module (Authority Layer) of the OpenAPI Generics platform
openapi-generics-contract is a framework-agnostic Java library that defines the
authoritative response model used across the OpenAPI Generics platform.
It is the only place where response semantics are defined. Everything else in the system either projects, interprets, or consumes this model.
The goal is simple:
Define response semantics once, preserve them across the entire lifecycle, and never duplicate or reinterpret them.
- Why This Module Exists
- Architectural Positioning (Critical)
- Design Philosophy
- Core Concepts
- Relationship with the Platform
- Explicit Non-Goals
- Dependency
- Compatibility Matrix
- Versioning Strategy
- When Should You Use This?
- Design Trade-offs
- Failure Philosophy
- Mental Model
Most HTTP APIs converge on the same shape:
- payload wrapped with metadata
- pagination and sorting structures
- structured error extensions
But in practice, these are often:
- duplicated across services
- regenerated in clients
- inconsistently evolved over time
This creates long-term problems:
- schema drift between producer and consumer
- duplicated DTO hierarchies
- fragile client regeneration
- unclear ownership of the API contract
openapi-generics-contract addresses this by introducing a single, shared contract
that both producers and consumers depend on directly.
Within the platform, this module is the authority layer:
| Layer | Role |
|---|---|
| Authority | openapi-generics-contract (this) |
| Projection | server starter (OpenAPI generation) |
| Enforcement | code generation (build-time) |
| Consumption | generated clients |
OpenAPI is a projection. This module is the authority.
- OpenAPI MUST NOT redefine these models
- generators MUST NOT re-generate them
- clients MUST reuse them directly
If this boundary is violated, contract drift is reintroduced.
The response envelope is:
- not generated
- not copied
- not redefined
It is defined once and reused everywhere.
Frameworks and generators are implementation concerns.
The response model is treated as a domain-level contract, not as a side-effect of tooling.
No dependency on:
- Spring
- Jakarta Web
- OpenAPI annotations
Only minimal JSON annotations are used.
Result:
- portable
- stable
- long-lived
The contract evolves additively:
- new fields → optional
- no breaking structural rewrites
ServiceResponse<T>Structure:
data→ payloadmeta→ contextual metadata
Example:
return ServiceResponse.of(customerDto);Meta contains contextual information:
- server time
- sorting
- future extensibility
Design:
- minimal
- extensible
- always present
Page<T>Standardizes:
- page index
- page size
- total elements
- navigation flags
Supported canonical shape:
ServiceResponse<Page<T>>Out of scope:
- arbitrary nested generics
- maps and complex containers
Rationale:
- deterministic schema generation
- stable client typing
Sort(field, direction)Simple, framework-neutral sorting model.
Provides:
ProblemExtensionsErrorItem
Used inside:
application/problem+json
This module does NOT implement error handling.
This module is intentionally independent but central.
- server starter reads these types
- projects them into deterministic OpenAPI schemas
- generator maps schemas back to these classes
- prevents model duplication
- enforces contract alignment
- generated clients extend these types
- ensures type consistency across boundaries
The same contract type flows through server → OpenAPI → client unchanged.
This module does NOT:
- generate OpenAPI
- implement controllers
- handle HTTP transport
- perform validation
- generate clients
Those responsibilities belong to other platform layers.
<dependency>
<groupId>io.github.blueprint-platform</groupId>
<artifactId>openapi-generics-contract</artifactId>
<version>1.0.0</version>
</dependency>Usage:
- server → compile
- client → compile / provided
| Component | Supported Versions |
|---|---|
| Java | 17+ |
Current state: pre-1.0
Meaning:
- API may evolve
- breaking changes are possible but controlled
Server and client MUST use the same contract version.
Use this module if:
- you expose typed REST APIs
- you generate clients from OpenAPI
- you want zero duplication of response wrappers
- you treat response shape as architecture (not implementation detail)
Only specific generic shapes are supported.
Gain:
- determinism
- predictability
No Spring shortcuts.
Gain:
- long-term stability
- portability
Only data structures.
Gain:
- explicitness
- no hidden logic
This module avoids hidden behavior.
If something breaks:
it should fail loudly in upper layers (server / codegen)
Think of this module as:
The canonical API language shared across your system
Not:
- a utility library
- a DTO collection
openapi-generics-contract is:
- the authority layer of the platform
- the single source of truth for response semantics
- a framework-agnostic contract module
Its responsibility is strictly:
Define response semantics once and preserve them across the entire lifecycle
Nothing more.
MIT — see LICENSE