API FEATURE
REST + GraphQL
Semitexa lets one use case answer both transports, so teams do not have to choose between REST and GraphQL too early.
Feature Guide
A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.
What this does
A single Semitexa use case can answer both REST and GraphQL. The public transports differ, but the business flow stays in one place.
How it works
An existing REST payload opts into GraphQL with #[ExposeAsGraphql(...)]. REST clients keep calling the normal HTTP route, GraphQL clients call POST /graphql, and both transports reuse the same application contract.
Why it matters
This matters when products are not ready to choose one public style forever. Semitexa lets teams support both without forking their use case into two implementations that drift apart over time.
Key concepts
- REST + GraphQL
- One use case exposed through two transports without duplicated handler logic.
- shared contract
- The same payload and output boundary stays authoritative across both transports.
- transport split
- REST and GraphQL can differ at the edge while still sharing the same application execution path.
REST + GraphQL
One Semitexa use case, two transports
These fields come from real REST payloads that also opt into GraphQL. REST clients keep their normal HTTP routes, GraphQL clients call POST /graphql, and the use case stays in one place.
Shared contract
Real GraphQL fields derived from the current REST API
productBySlug
Derived GraphQL field for loading one product by slug from the Semitexa demo catalog.
- Already have
GET /demo/api/v1/products/{slug}- GraphQL result
query.productBySlug- Returns
ProductGraphqlView
query {
productBySlug {
slug
name
price
category {
name
}
}
}
products
Derived GraphQL field for paginated product collection reads from the Semitexa demo catalog.
- Already have
GET /demo/api/v1/products- GraphQL result
query.products- Returns
ProductListGraphqlView
query {
products {
items {
slug
name
price
}
total
page
limit
}
}
Pseudo SDL
What GraphQL can expose from the same use case
type Query {
productBySlug: ProductGraphqlView
products: ProductListGraphqlView
}
Verified against Semitexa Ultimate 2026.09.19.1020
REST + GraphQL
Semitexa lets one use case answer both transports, so teams do not have to choose between REST and GraphQL too early.
How it works
A Payload DTO marked with both #[ExternalApi] and #[ExposeAsGraphql] registers the same operation into both the REST route table and the GraphQL schema. The handler is written once. The framework dispatches the same handler for both an HTTP GET request and a POST /graphql query targeting the same field. The output DTO is the same in both cases.
Why this matters
Transport-level decisions are often made before the product is stable. Semitexa's dual-transport model delays that commitment: you write one handler now and surface it as REST or GraphQL or both later. The alternative — maintaining separate handler and resolver trees for each transport — creates divergence that grows with every new field or behavior change.
How it works
An existing REST payload opts into GraphQL with #[ExposeAsGraphql(...)]. REST clients keep calling the normal HTTP route, GraphQL clients call POST /graphql, and both transports reuse the same application contract.
Why it matters
This matters when products are not ready to choose one public style forever. Semitexa lets teams support both without forking their use case into two implementations that drift apart over time.
Key concepts
- REST + GraphQL
- One use case exposed through two transports without duplicated handler logic.
- shared contract
- The same payload and output boundary stays authoritative across both transports.
- transport split
- REST and GraphQL can differ at the edge while still sharing the same application execution path.