Add note on default responses if extraction fails

[simon-amadeus]

Motivation

The default error response for failed extractions may expose internal details, such as library paths.
This may expose internal details through a public interface without notice.

Edit: See this discussion to have more context.

Solution

Add note in the documentation about default response behavior, if extraction fails.

Fixes #1167

[davidpdrsn]

Maybe it's more appropriate to mention here. wdyt?

[simon-amadeus]

Yes, I thought about it. Default behavior is sort-of mentioned here but I though one might skip reading this section if not interested in customizing responses.

Actually I digged a bit deeper into how default rejections are implemented and I saw, that library internals are only exposed when extracting query parameters.

impl std::fmt::Display for FailedToDeserializeQueryString {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(
            f,
            "Failed to deserialize query string. Expected something of type `{}`. Error: {}",
            self.type_name, self.error,
        )
    }
}

For comparison, the default json response does not expose such details, even if a field is missing. It simply names the field in the response body:

Example of Json response:
Failed to deserialize the JSON body into the target type: missing field 'has_accepted_terms' at line 4 column 1

Example Query response:
Failed to deserialize query string. Expected something of type 'registration_service::routes::registrations::RequestParams'. Error: missing field 'email'

Just to avoid misunderstandings:
You really think it is necessary to include self.type_name in the error message?

[davidpdrsn]

Yes, I thought about it. Default behavior is sort-of mentioned here but I though one might skip reading this section if not interested in customizing responses.

My experience is that people don't read the docs anyway and putting everything on the front page is a slippery slope 😛

You really think it is necessary to include self.type_name in the error message?

Ah you're right. Yeah we should probably remove the type name from Query's rejection. Wanna make a PR for that?

[simon-amadeus]

Closing as this has been resolved by #1171