Either-style type in query parameters

[Chiffario]

Summary

I've been trying to add a query parameter that can be either of the two provided types (in my case - u64 or String)

#[derive(PartialEq,Eq,serde::Serialize,serde::Deserialize,Debug)]
#[serde(untagged)]
pub enum IdOrName {
    Id(u64),Name(String),
}

This approach works for normal JSON, however, when trying to test this with query parameters, the value is always deserialized as a string. For example, the following code

    #[derive(PartialEq, Eq, serde::Deserialize, Debug)]
    struct TestQuery {
        foo: IdOrName,
        bar: u64,
    }
    #[test]
    fn test_query_query_de() {
        let uri: Uri = "http://example.com/path?foo=1&bar=222".parse().unwrap();
        let result: Query<TestQuery> = Query::try_from_uri(&uri).unwrap();
        assert_eq!(
            result.0,
            TestQuery {
                foo: IdOrName::Id(1),
                bar: 222,
            }
        );
    }

yields the following test failure

assertion left == right failed
left: TestQuery { foo: Name("1"), bar: 222 }
right: TestQuery { foo: Id(1), bar: 222 }

---

Is there a good way to get around this? Or do I have to implement manual deserialization for the enum?

axum version

0.8.4

[jplatte]

You have to implement Deserialize manually for this. You'll probably want to call String::deserialize first, then attempt to parse that into an integer and if the parsing fails, return the string variant.

[Chiffario]

Gotcha, seems fair. Is there any reason why it doesn't work "out of the box"?

[jplatte]

Yes, because there is nothing in the urlencoded format to tell serde "this is a number" vs. "this is a string". I guess in theory serde_urlencoded could treat all-digit values differently even outside of the Deserialize impl requesting a number, but personally I would find this very surprising.

[mladedav]

I'll just add that it works with json because 123 is not a valid string so it has to deserialize to the number variant. For queries, 123 is both a valid string and a number. I'm not sure if you can depend on the order of untagged variants in serde.

[Chiffario]

Yes, because there is nothing in the urlencoded format to tell serde "this is a number" vs. "this is a string". I guess in theory serde_urlencoded could treat all-digit values differently even outside of the Deserialize impl requesting a number, but personally I would find this very surprising.

very fair, didn't consider that. Thanks!