The Prefer header for HTTP (RFC 7240) allows that a client can communicate a preference for handling minor issues in a request:
The "handling=strict" and "handling=lenient" preferences indicate, at the server's discretion, how the client wishes the server to handle potential error conditions that can arise in the processing of a request. For instance, if the payload of a request contains various minor syntactical or semantic errors, but the server is still capable of comprehending and successfully processing the request, a decision must be made to either reject the request with an appropriate "4xx" error response or go ahead with processing. The "handling=strict" preference can be used to indicate that, while any particular error may be recoverable, the client would prefer that the server reject the request. The "handling=lenient" preference, on the other hand, indicates that the client wishes the server to attempt to process the request.
This capability is useful for APIs supporting the mutation of resources.
For example, a client can communicate to a Features API whether the API should accept or reject a new feature that is not valid against the schema for the features in the collection, but that the API could still store in its internal data store (e.g., if a property is not provided, but that property is marked as required in the receivables schema).
The editor's draft of OGC API Styles, which normative references Features Part 4 for the mutation of styles, already includes a requirements class that leverages the Prefer header for this purpose.
As this is general capability, we should consider to move the capability to Features Part 4 for all resource types.
The Prefer header for HTTP (RFC 7240) allows that a client can communicate a preference for handling minor issues in a request:
This capability is useful for APIs supporting the mutation of resources.
For example, a client can communicate to a Features API whether the API should accept or reject a new feature that is not valid against the schema for the features in the collection, but that the API could still store in its internal data store (e.g., if a property is not provided, but that property is marked as required in the receivables schema).
The editor's draft of OGC API Styles, which normative references Features Part 4 for the mutation of styles, already includes a requirements class that leverages the Prefer header for this purpose.
As this is general capability, we should consider to move the capability to Features Part 4 for all resource types.