Handling JSON files in Rust without manually creating mapping classes


I have JSON that looks something like this:


The JSON data is named CharacterInfo. It comes from a static external URL. The structure of this information could be changed, as it comes from an outside source and updates occur.

In rust the mapping class using Serede looks something like this:

#[derive(Serialize, Deserialize, Debug, PartialEq)]
pub struct CharacterInfo {
    pub id: String,
    pub name: String,
    #[serde(rename = "revisionDate")]
    pub revision_date i64: 

The CharacterInfo class needs to be referenced in code. It's an API wrapper library, so the method looks something like this:

pub fn get_character_info() -> Result<CharacterInfo, HttpError> {
    let http_result = HttpClient::get(Self::CHARACTER_INFO_URL);

    match http_result {
        Ok(result) => {
            let character_info: CharacterInfo = serde_json::from_str(&result).unwrap();

        Err(error) => Err(error),

The problem is the JSON files could change and there are a lot of them. Generating them manually would be tedius.

Generating the .rs mapping classes Is not that difficult, in fact websites already exist to do this (

But I'm not sure how I could have my Rust program compile or use the .rs files after creating. Also would this be considered hacky / bad practice? Is there a better way?

Why should this post be closed?


How much work are you interested in doing when the JSON format changes? Are you trying to avoid recompilation altogether? Or do you just want the recompilation not to involve too much manual effort? ‭r~~‭ 14 days ago

I'd like no manual work if the JSON changes. It does not matter if recompilation is needed on updates ‭dustytrash‭ 14 days ago

1 answer


The hard part is figuring out exactly how your code needs to adapt to changes in the JSON structure. In your example, presumably the rest of your program needs to depend on the names and types in

pub struct CharacterInfo {
    pub id: String,
    pub name: String,
    pub revision_date i64: 

being what they are. So if the JSON ever drops one of those fields, or if their types change, then I don't see how an automated process could ever adjust your program to adapt without any manual intervention. (I mean, I could imagine some sort of refactoring tool that's capable of renaming and/or retyping fields throughout your program, but I don't know of such a tool for Rust yet.)

To do this in an automated way, I'd say you need to be able to write code that can take an input JSON object and figure out what its mapping to your canonical CharacterInfo struct needs to be. I don't know exactly how you'd do that; it depends on how you expect the JSON to change. Maybe you do things like check for any JSON field names that contain id as a substring and map them to your id field? Maybe you're expecting only casing to change, and so you normalize the field names to all lowercase before mapping them? Maybe you're anticipating a common prefix or suffix being added to all the JSON field names so you test for that? There are a lot of possibilities and edge cases to consider here, and you will have to consider them yourself.

But if you can write code to generate that mapping, then you have two options. The simpler is to manually implement Deserialize for CharacterInfo yourself by invoking that code at runtime. Writing deserializers by hand isn't that hard, and isn't hacky if you're trying to target a range of possible JSON input formats. (It gets uglier if you also need to Serialize these structs back to the original JSON format; then you might need to do something awkward like keep a global holding the last mapping used to deserialize a CharacterInfo, or add fields to CharacterInfo containing extra JSON data and/or the mapping used.)

The other option is to get fancy with macros. A proc_macro_attribute-style macro is probably capable of rewriting your CharacterInfo struct to contain the necessary Serde attributes to remap fields as needed. This has the advantage of doing all the fussing with figuring out the mapping at compile time. It has the disadvantages of requiring a whole separate crate for your macro implementation, and having to get your hands dirty in the guts of Rust macros, and probably raising a few eyebrows if anyone other than you needs to maintain this code. It's very likely to be more work than just implementing a Deserialize for each of your structs.


Sign up to answer this question »