Add option to throw validation error on extra keys

I’m not sure if I’m missing something, but I would like to throw error if extra keys are provided, as in:

>>> class AlbumSchema(Schema):
...     title = fields.Str()

>>> AlbumSchema(strict=True).load({'extra': 2}, allow_extra=False)
Traceback (most recent call last):
...
marshmallow.exceptions.ValidationError: {'_schema': ["Extra arguments passed: ['extra']"]}

I’ve been using the following implementation (taken from https://github.com/sloria/webargs/issues/87#issuecomment-183949558):

class BaseSchema(Schema):

    @pre_load
    def validate_extra(self, in_data):
        if not isinstance(in_data, dict):
            return

        extra_args = [key for key in in_data.keys() if key not in self.fields]
        if extra_args:
            raise ValidationError('Extra arguments passed: {}'.format(extra_args))

I would expect this to be a common need, however, so could it be supported by the library out-of-the-box?

[sloria]

We still need to decide on a default. I think we should rule out “allow”–it is too permissive for the common use case. That leaves “ignore” and “raise”.

Let’s take a poll:

Add an emoji reaction to this comment with your vote.

😄 = “ignore” - Discard unknown fields but don’t error. This is the current behavior. DRF, Colander, and Valideer have this as the default. 🎉 = “raise” - Raise an error for unknown fields. Voluptuous, Cerberus, schema, and Schematics have this as the default.

[bivald]

+1

In my case it’s to avoid ambiguity. The API expects a set of keys to be present per method and only those keys. We use Marshmallow to power an API and you really want the boundaries of each API method to be crisp. I don’t want anyone to be able to “think”/“guess” that a key is valid because the API accepts it without sending an error.

A different use case is what I got from one of our developers today:

“I’m creating a page with a title and a slug but the API doesn’t accept the slug. It gives no error, it just creates a slug based on the title instead.”

Turns out the user sent the following JSON payload:

{
   "page_title": "My Page Title",
   "slug": "a-specific-slug"
}

But our API wants page_title and page_slug. However, supplying the slug is optional. So it doesn’t complain if the slug isn’t present, it just defaults to creating a slug from the title.

The backup option for us is to force page_slug key, but letting it be False if you want to auto-generate it. Perhaps thats what we’ll go with.

So that’s my use case.