Ignore extra fields in REST payloads

[Aniruddh25]

If a property points to a field that doesn’t exist the operation will succeed anyway, ignoring the mismatched fields, unless otherwise specified via the x-ms-match-mode request header.

If the operation is successful, the 201 HTTP code will be returned. The result will be the JSON object of the added item, unless otherwise specified via the x-ms-result request header.

[JelteF]

I think we should be strict by default and not allow specifying fields that don't exist. It's almost always a bug in the user their code if they provides a value for a field that does not exist.

[JelteF]

Also, why use a header to supply the fields? We already have a way to specify which fields we want with the _f query parameter, seems better to stay consistent across the APIs.

[Aniruddh25]

This needs discussion, the description wasn't clear. It has nothing to do with _f query parameter.

Here is the intention of this custom header from the REST spec which has not been fully discussed yet, hence the issue.

x-ms-match-mode
The x-ms-match-mode request header specifies how to deal with unmatched JSON properties. The header is optional, and the default is set to ignore. There are two possible valid options for this header:

ignore: if passed JSON has properties that does not match with any field in the target database object, just ignore them

strict: if passed JSON has properties that does not match with any field in the target database object, return an error

[Aniruddh25]

This issue should be handled at the end after we have other issues taken care of.

By default, today we are in strict mode for REST. If we release in strict mode without implementing, x-ms-match-mode then perhaps need its default to be strict mode as well.