Leave logic of deciding on extra args to schema

Now that marshmallow 3.x is in beta and comes with configurable behavior on extra args, how about just including all fields in Parser._parse_request() and passing them on to Schema.load()? It would be up to passed Schema to determine what to do with them.

The effect would be that:

• With RAISE, extra fields would be denied.
• With INCLUDE, extra fields would be allowed and passed on.
• With EXCLUDE, extra fields would be ignored.

This would allow something like:

@use_args(HeaderSchema(unknown=EXCLUDE), locations=('headers', ))
@use_args({'action': fields.Str()}, locations=('json',))  # default is RAISE

Actually, I don’t think this even needs marshmallow 3.x. Why not just always pass all fields from _parse_request() to Schema.load()? On 2.x you would need custom @validates_schema implementation in addition, but on 3.x you would not.

Maybe I’m missing something…

[pzhang65]

Wow wasn’t expecting such a fast response. Thanks for the tip, I’ll take a quick look at writing my custom parser but maybe it’ll make more sense I try build on aiohttp-apispec to support webargs >=6.

[lafrech]

I think the fact that you need to ask that question – “what would it do?” – means it should not be supported.

We’re on the same line. All I’m saying is that not supporting this removes a feature with no real workaround.

Currently, using a Schema with multiple locations means for each field, try to fetch the data from one location then from the other if the first fail. Each field may come from any location.

The workaround you propose tries the whole Schema on a location then the whole Schema again on the second if the first fails validation. This is not equivalent. To propose something equivalent, you’d need to load partial from the first location, then the second, then merge both results. Then check required fields. It already sounds awful.

I can’t really think of an API that would expect some inputs from several locations. I mean an API may accept a payload in json and query parameters in the same request, but I’d find it weird to build a loose API with a POST /users/ resource where user.age could be specified either in json or in query param, etc. Mixed location is fine, as long as each field can only come from one location.

In other words, I wouldn’t mind dropping this feature and enforce a single location for a field. On one hand, people may be relying on it, but we don’t know that. On the other hand, if someone wanted to add this feature, we’d probably reject that because it adds complexity for what is arguably a smelly edge case.

Overall, the proposal is

• drop location argument to Field
• only accept a single location in use_args

Whether we use nested calls to use_args for different locations or a single call with a {location: schema} mapping is just an interface choice.