Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Handling JSON files in Rust without manually creating mapping classes
I have JSON that looks something like this:
{"id":"n-fsdf-6b6",
"name":"JohnSmith",
"revisionDate":1591072274000}
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();
Ok(character_info)
}
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 (https://transform.tools/json-to-rust-serde).
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?
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.
1 comment thread