Forcing 422 Unprocessable Content

Mechanism: Per RFC 9110 §15.5.21, a server returns 422 when the payload fails semantic validation. The server must find the resource and load its schema before it can validate.

Isolated Variable: The Content-Type remains valid. Only the values within the body are made semantically invalid.

Oracle Signal: 422 (exists) vs 404 (does not exist).

PATCH — Existing Resource (Wrong Type)

PATCH /api/users/1001 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 14

{"age": "old"}

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"error": "Validation Failed", "detail": [{"field": "age", "message": "must be an integer"}]}

PATCH — Non-Existing Resource (Wrong Type)

PATCH /api/users/9999 HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 14

{"age": "old"}

HTTP/1.1 404 Not Found
Content-Type: application/json

{"error": "Not Found"}

💡 Error message granularity as a secondary oracle: The 422 body often includes field-level validation details — field names, expected types, constraint descriptions — that leak the resource's schema. Each different invalid payload reveals a different constraint.

Mitigation: Perform resource existence checks before body validation. Return 404 for non-existent resources without inspecting the request body.