Generate Rust models and review their Serde mapping
JSON to Rust generates a draft set of types for a JSON sample. It can speed up the first pass of modeling nested records in a Rust project.
When should you use it?
- Sketch types for an API client.
- Compare fixture fields against a Serde model.
- Identify arrays and nullable values in nested data.
Example: infer Rust fields from JSON
This abbreviated example shows the inferred name and active fields in Rust. The full generated file includes imports and helpers and may change with generator versions; review it before adding it to a project.
{"name":"Alex","active":true}#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct Root {
pub name: String,
pub active: bool,
}Connect Rust field names to the JSON contract
Rust naming conventions can differ from API property names. Review the generated Serde attributes, imports, and helper functions together so renaming a field does not change the wire contract. Nested objects and arrays can become named structs and vectors, which makes a complex response easier to use than unstructured field lookups.
Choose the right representation for uncertain values
Option types, numeric ranges, and enum variants need representative samples and a known contract. A field that is always populated in one response may still be absent in another. Review values that can change type or exceed an integer range, and test deserialization in your actual crate setup. The generator does not compile the result against your dependency versions on this page.
How do I generate Rust structs for a JSON API response?
Generate Rust source from a representative sample and inspect the Serde-derived model. The tool infers observed names and types, which is useful for prototyping deserialization before refining field renames and optional values.
Illustrative Rust Serde model
rustuse serde::{Serialize, Deserialize};
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct Root {
pub name: String,
pub active: bool,
}Add the required crates in your project and review integer widths, Option fields, and naming conventions.
Why might deserialization fail on another API response?
That response may omit a field, contain null, or use another type not represented in the sample. Update the model after testing multiple real shapes.
What should you check before using the result?
Check crate dependencies, derives, field renames, Option choices, lifetimes, and numeric widths before compiling. Runtime behavior depends on your deserializer.
Understand JSON syntaxTechnical reference: quicktype model generation documentation