Use case
The generated Rust API cannot always be reconstructed from the source OpenAPI document.
Identifier normalization, naming collisions, inline types and generated method variants affect the actual symbols and signatures.
Downstream tools currently have to parse generated Rust or reproduce the generator's naming and type-resolution rules. Both approaches are fragile and can diverge from the code actually emitted.
This differs from the client-sync manifest introduced in #48, which describes generation inputs rather than the generated Rust API.
Area
Packaging, docs, or integrations
Representative OpenAPI fragment
openapi: 3.1.0
info:
title: Binding metadata example
version: 1.0.0
paths:
/items/{item-id}:
get:
operationId: getItem
parameters:
- name: item-id
in: path
required: true
schema:
type: string
- name: mode
in: query
schema:
type: string
enum: [fast, safe]
responses:
"200":
description: OK
content:
application/json:
schema:
$ref: "#/components/schemas/Item"
components:
schemas:
Item:
type: object
required: [id]
properties:
id:
type: stringDesired generated API or behavior
Expose an optional, deterministic and versioned description of the Rust bindings actually emitted by the generator.
It should include public structs, fields, enums, aliases and symbol paths; exact generated client method signatures; and canonical source OpenAPI operation identities.
Where one operation produces multiple methods, the metadata should distinguish their response representations without inferring semantics from generated Rust names.
The metadata should share the same naming, type-resolution and operation-planning decisions as source rendering, rather than reconstructing them afterward.
An opt-in JSON artifact and an additive library API would support both CLI and library consumers. The initial schema is open for discussion.
Alternatives considered
Parsing generated Rust with syn couples consumers to source layout and requires them to reconstruct the relationship between Rust symbols and OpenAPI operations.
Reimplementing name allocation and type resolution downstream risks diverging from the generator's actual output.
Extending the existing client-sync manifest would mix generation-input orchestration with generated-output introspection. These have different responsibilities and compatibility requirements.
Compatibility
Use case
The generated Rust API cannot always be reconstructed from the source OpenAPI document.
Identifier normalization, naming collisions, inline types and generated method variants affect the actual symbols and signatures.
Downstream tools currently have to parse generated Rust or reproduce the generator's naming and type-resolution rules. Both approaches are fragile and can diverge from the code actually emitted.
This differs from the client-sync manifest introduced in #48, which describes generation inputs rather than the generated Rust API.
Area
Packaging, docs, or integrations
Representative OpenAPI fragment
Desired generated API or behavior
Expose an optional, deterministic and versioned description of the Rust bindings actually emitted by the generator.
It should include public structs, fields, enums, aliases and symbol paths; exact generated client method signatures; and canonical source OpenAPI operation identities.
Where one operation produces multiple methods, the metadata should distinguish their response representations without inferring semantics from generated Rust names.
The metadata should share the same naming, type-resolution and operation-planning decisions as source rendering, rather than reconstructing them afterward.
An opt-in JSON artifact and an additive library API would support both CLI and library consumers. The initial schema is open for discussion.
Alternatives considered
Parsing generated Rust with syn couples consumers to source layout and requires them to reconstruct the relationship between Rust symbols and OpenAPI operations.
Reimplementing name allocation and type resolution downstream risks diverging from the generator's actual output.
Extending the existing client-sync manifest would mix generation-input orchestration with generated-output introspection. These have different responsibilities and compatibility requirements.
Compatibility