BodyValidator is ill-conceived, we should replace it entirely with the mechanism introduced by T358558, namely overriding getBodyParamSettings and, if needed, parseBodyData.

Rationale

BodyValidator currently conflates several concerns:

• parsing the request body stream (deserializing)
• validating the schema of the request body
• validating parts of the request body semantically
• constructing a domain specific representation of the request body (validateBody and getValidatedBody return mixed)

The only implementation of BodyValidator is JsonBodyValidator, which implements parsing and incomplete schema validation (see T305973). It always returns an array. Handlers that use JsonBodyValidator implement higher level validation and domain specific logic based on that array.

BodyValidator seems overly generic: callers of validateBody cannot make use of the return valus, unless they know the concrete type of the validator. If they know the concrete type of the validator, they could just as well apply validation diretly.

Proposal

Do address this, we should:

• Implement body parsing separately: T357025: Add getParsedBody to RequestInterface in the REST framework
• Implement body schema validation separately: T358558: Rest ParamValidator should support validation of fields in the request body
• Add a mechanism for specifying a JSON Schema for complex body fields: T362108: Implement JSON schema validation in ArrayDef
• deprecate Handler::getBodyValidator as well as the BodyValidator class and all of its subclasses.

See also the discussion recorded at https://drive.google.com/file/d/1rwM9TqjliJcJwj5XIg22gD8mfqVdHcdH/view