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 parent resource and load its schema before it can validate — so a 422 implies the resource was resolved.

Isolated Variable: The Content-Type and request structure remain valid. Only the values within the body are made semantically invalid.

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

POST — Existing Parent Resource (Invalid Sub-Resource Payload)

POST /api/users/1001/addresses HTTP/1.1
Host: target.com
Content-Type: application/json
Content-Length: 2

{}

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

{"error": "Validation Failed", "detail": [{"field": "street", "message": "required"}]}

vs. 404 when user 1001 does not exist.

💡 422 vs 400 — Oracle Implications: Some servers return 400 Bad Request instead of 422 for semantic validation failures. The oracle logic is identical (400 vs 404). To isolate the variable, always send syntactically perfect payloads so any 400/422 is definitively a schema-validation response.

💡 Error message granularity as a secondary oracle: The 422 body often includes field-level validation details that leak the resource's schema. Compare response bodies, not just status codes.

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