warp
warp copied to clipboard
seanmonstar
Document that filters::query::query uses serde_urlencoded, and add example for postprocessing filters::query::raw
serde_urlencoded is used for to deserialize query strings, and hence not all structs that are Deserialize can be deserialized to. I think it would be neat to document that fact and also added an example that shows how to use a different deserialization function instead.
(I didn't want to add serde_qs as a dev-dependency just for this, so I fudged it.)
What do you think?
Yes this is a great idea, thanks! I wonder, what if instead of "promising" to use serde_urlencoded, we just say that currently the decoder strictly follows the URL spec, and so cannot decode lists etc.
currently the decoder strictly follows the URL spec
Hm, I'll rephrase it like that. But I do wonder whether it's accurate, or at least helpful.
On the one hand side, the URL spec allows duplicated keys (okay, it'd be odd to expect that to work with rust structs structs), on the other hand side, serde_urlencoded supports tagged/untagged enums, which I had not expected to work at all (but only if all values are String).
Then again, mentioning serde_urlencoded does not help that much, since these things aren't documented.
I don't see how #843 documents what limitations the limitations of query parameter deserialization. I wouldn't consider this addressed. But I do feel like I'm being pedantic. In the off-case that you want me to renovate this PR, please do tell.
Oh sorry! And no, not pedantic at all, if you want to rebase your PR against master and add the limitations of parameter deserialization that would be great!
I've rebased on master and reworded it so the documentation doesn't leak any implementation details.
Ah, if you're asking, I should probably spell it out. Parameters. But I'll change it to FooQuery to match the other example.