Handling different ways to represent null in serde

Question

I'm writing a client library around this REST server. Octoprint (A server to manage a 3d printer), to be precise.
Here's one of the types i'm working with:

#[derive(Serialize, Deserialize, Debug)]
pub struct JobInfo {
    /// The file that is the target of the current print job
    pub file: FileInfo,
    /// The estimated print time for the file, in seconds
    #[serde(rename = "estimatedPrintTime")]
    pub estimated_print_time: Option<f64>,
    /// The print time of the last print of the file, in seconds
    #[serde(rename = "lastPrintTime")]
    pub last_print_time: Option<f64>,
    /// Information regarding the estimated filament usage of the print job
    pub filament: Option<Filament>,
}

Pretty straightforward, Using the multiplicity property defined in the specification of the API, I determined which properties should be considered optional, hence why some of these props are wrapped in options.

Unfortunately the documentation lies a little bit in the way multiplicity works here; here's an example on what a response looks like when the printer is in an offline state. For the sake of brevity, I will omit most of the body of this JSON message and keep just enough to get the point across

{
"job": {
    "file": null,
    "filepos": null,
    "printTime": null,
    ... etc
},
...
"state": "Offline"
}

Here's the type that I'm expecting for this response:

#[derive(Serialize, Deserialize, Debug)]
pub struct JobInformationResponse {
    /// Information regarding the target of the current print job
    job: JobInfo,
    /// Information regarding the progress of the current print job
    progress: ProgressInfo,
    /// A textual representation of the current state of the job
    /// or connection. e.g. "Operational", "Printing", "Pausing",
    /// "Paused", "Cancelling", "Error", "Offline", "Offline after error",
    /// "Opening serial connection" ... - please note that this list is not exhaustive!
    state: String,
    /// Any error message for the job or connection. Only set if there has been an error
    error: Option<String>,
}

Now I could just wrap all of these types in Options, but the previous example json wouldn't parse, since technically since job is an object, it's not going to deserialize as None despite the fact that each of it's keys are null. I was wondering if there were some sort of attribute in serde that would be able to handle this weird kind of serialization issue. I'd like to avoid just wrapping every single property in Options just to handle the edge case where the printer is offline

Edit: I guess what I'm trying to say is that I would expect that if all props on a struct in the json representation were null, that the object itself would serialize as None

Answer 1

If you're willing to redesign a little bit, you might be able to do something like this:

#[serde(tag = "state")]
enum JobInformationResponse {
    Offline {}
    // If a field only appears on one type of response, use a struct variant
    Error { error: String },
    // If multiple response types share fields, use a newtype variant and a substruct
    Printing(JobInformationResponseOnline),
    Paused(JobInformationResponseOnline),
    // ...
}
struct JobInformationResponseOnline {
    job: JobInfo,
    progress: ProgressInfo,
}

This works in the Offline case because by default, serde ignores properties that don't fit into any field of the struct/enum variant. So it won't check whether all entries of job are null.

If you have fields that appear in every message, you can further wrap JobInformationResponse (you should probably rename it):

struct JobInformationResponseAll {
    field_appears_in_all_responses: FooBar,
    #[serde(flatten)]
    state: JobInformationResponse // Field name doesn't matter to serde
}

But I'm not sure whether that works for you, since I certainly haven't seen enough of the spec or any real example messages.

To answer your question directly: No, there is no attribute in serde which would allow an all-null map to be de/serialized as None. You'd need two versions of the struct, one without options (to be used in your rust code) and one with (to be used in a custom deserialization function where you first deserialize to the with-options struct and then convert). Might not be worth the trouble.

And a side note: You might be happy to find #[serde(rename_all = "camelCase")] exists.