openapiv3
Typed Rust structs and enums for the OpenAPI v3.0 specification, built for serde.
Repository Health
Technical Analysis
openapiv3 is a Rust crate that provides data structures representing the OpenAPI v3.0.x specification, designed to map cleanly to Rust structs and enums for easy deserialization with serde. You point serde at an OpenAPI JSON or YAML document and get a strongly typed OpenAPI value you can inspect and manipulate.
The crate models the full v3.0 surface — paths, operations, schemas, parameters, responses, components, security schemes, and more — using idiomatic enums such as a reference-or-item type. Note it targets v3.0 and does not cover the incompatible v3.1 revision.
What You Get
- A complete typed model of the OpenAPI v3.0.x specification
- Clean serde-based deserialization from JSON or YAML into an
OpenAPIvalue - Dedicated types for paths, operations, schemas, parameters, responses, and components
- A
ReferenceOrenum for handling$refreferences versus inline items
Common Use Cases
- Parsing an OpenAPI spec to drive code or client generation
- Validating or inspecting API definitions programmatically
- Building tooling that transforms or analyzes OpenAPI documents
Under The Hood
Architecture - The crate is a flat, well-factored set of modules under src/, each mapping to one OpenAPI concept: openapi.rs defines the root OpenAPI type, with paths.rs, operation.rs, schema.rs, components.rs, parameter.rs, responses.rs, security_scheme.rs, and peers modeling the rest. A shared variant_or.rs provides the ReferenceOr enum used pervasively to represent $ref-or-inline values, and util.rs holds helpers.
Tech Stack - Rust built with Cargo. It leans on serde (with derive) for (de)serialization and indexmap/serde_json for ordered maps and JSON handling, keeping the dependency footprint small and focused on data modeling.
Code Quality - The code is straightforward and consistent, with one type per file and heavy use of serde attributes rather than hand-written parsing. It is a mature, low-churn crate; correctness rests largely on the type definitions matching the spec, and the README is candid about known edge cases (e.g. typeless schemas).
API Design - Usage is minimal: deserialize into OpenAPI and navigate typed fields. The ReferenceOr pattern is intuitive, field names track the spec closely, and there is essentially no setup boilerplate, making the crate easy to adopt for anyone familiar with OpenAPI.