I'm sure it could be (possibly breaking the current serde API), but I think I'd prefer it be a runtime option. That way you can toggle it on and off for different uses of different APIs.
For example, my service might deserialize in two different places: 1) when deserializing request bodies sent from clients, and 2) when deserializing response bodies when making API calls to other services.
I might want to enable this feature for #1 (so I can return complete error messages to clients), but disable it for #2 (because I expect this issue to be rare, and don't want to incur a performance penalty when handling deserialization errors if remote API servers give me something I don't expect).
I think that each request needs some extension to ask for this if needed. Which would be enabled if there's a person typing data used to craft the request. If there's no human actively involved you can reject bad requests eagerly and save resources (and hopefully don't get hammered with bad requests)
I'm sure it could be (possibly breaking the current serde API), but I think I'd prefer it be a runtime option. That way you can toggle it on and off for different uses of different APIs.
For example, my service might deserialize in two different places: 1) when deserializing request bodies sent from clients, and 2) when deserializing response bodies when making API calls to other services.
I might want to enable this feature for #1 (so I can return complete error messages to clients), but disable it for #2 (because I expect this issue to be rare, and don't want to incur a performance penalty when handling deserialization errors if remote API servers give me something I don't expect).
I think that each request needs some extension to ask for this if needed. Which would be enabled if there's a person typing data used to craft the request. If there's no human actively involved you can reject bad requests eagerly and save resources (and hopefully don't get hammered with bad requests)