A request body is well-formed JSON and matches the declared content type, but breaks a schema or business rule. Would you answer with HTTP status 400 or HTTP status 422, and what distinction do those two codes actually carry?
answer
- 400 = did not parse; 422 = parsed, did not make sense
- 422 moved from WebDAV into RFC 9110 core
- no client behaves differently between them
- 409 = state conflict, 415 = media type, not validation
- consistency across the API beats purity
basics
~20 s400 means the request itself is malformed - bad syntax, unparseable JSON, missing required parameter. 422 means the syntax parsed fine but the content was semantically unprocessable. Both are non-retryable client errors; pick one convention and apply it API-wide.
solid answer
~50 sRFC 9110 defines 400 as a generic client error - the server will not process the request because something about it is wrong, classically malformed syntax. 422 Unprocessable Content, which RFC 9110 pulled into core HTTP from WebDAV, is narrower: the media type was understood and the syntax was correct, but the server could not process the contained instructions. So the clean split is parse failure versus rule failure. Unparseable JSON, a wrong content type, a non-numeric value in an integer path segment - 400. Valid JSON where email is not an email, quantity is negative, or endDate precedes startDate - 422. Honestly, both are correct in the sense that no client behaves differently: both are 4xx, neither should be retried unchanged, and many large APIs use 400 for everything while others use 422 for everything. What matters is that one convention holds across the API so clients can write one handler. I document the rule and enforce it in a shared handler.
code
http · 16 linesPOST /orders HTTP/1.1
Content-Type: application/json
{ "quantity": 2, <- trailing junk
HTTP/1.1 400 Bad Request
POST /orders HTTP/1.1
Content-Type: application/json
{ "quantity": -3 }
HTTP/1.1 422 Unprocessable Content
Content-Type: application/json
{ "errors": [ { "target": "/quantity", "code": "range.min", "message": "must be at least 1" } ] }go deeper
State the rule of thumb: 400 when the request could not be parsed, 422 when it parsed but broke a rule, and both mean the client must fix and resend.
Cite RFC 9110 for both, place 409/415/412 correctly, and note that the useful detail lives in the body regardless of which code you send.
Emphasise that consistency is the real requirement, enforce it in one handler, and mention observability - splitting one failure mode across two status buckets breaks dashboards and alerts.
Rule it at platform level, weigh cost of change on existing clients, and make the choice a documented standard with conformance tests rather than a per-team debate.
## What the specs actually say **400 Bad Request** (RFC 9110): the server cannot or will not process the request due to something perceived to be a client error - the canonical examples being malformed request syntax, invalid request message framing, or deceptive request routing. It is the catch-all of the 4xx range. **422 Unprocessable Content** (RFC 9110, promoted from WebDAV's RFC 4918 where it was Unprocessable Entity): the server understands the content type of the request content, and the syntax of the request content is correct, but it was unable to process the contained instructions. In other words, it parsed - it just does not make sense. ## The practical dividing line Draw a line at parsing. Before the body becomes an object: truncated or invalid JSON, a body sent as text/plain when JSON is declared, a string where the schema demands a number, an unparseable value in a query parameter. Nothing downstream can even run. That is 400. After the body becomes an object: a syntactically fine string that is not a valid email, a quantity of -3, a currency the account is not enabled for, an end date before a start date. Your validators ran and said no. That is 422. ## Why this is a convention question, not a truth question No mainstream client library treats 422 differently from 400. Neither is retryable as-is; both mean fix the request. Big public APIs sit on both sides - some return 422 for every rule violation, others never emit 422 at all. The cost of inconsistency is far higher than the cost of choosing the theoretically weaker option: if half your endpoints answer 400 and the other half 422 for the same class of failure, every client grows an if-either branch, and error-rate dashboards split a single phenomenon across two buckets. The common pragmatic rules are: (a) 400 for everything, with the machine-readable code array carrying the detail; or (b) 400 for parse and framing errors, 422 for semantic rule failures. Both are defensible. Write it down, put it in one exception handler, and be done. ## Codes that are not the answer Be explicit about the neighbours, because interviewers probe them. **409 Conflict** is for a clash with the current state of the target resource - a duplicate that violates uniqueness, or an edit against a stale version - not for a bad field. **403** is authorisation, not validation. **404** should not be used to hide a validation failure. **412 Precondition Failed** answers a conditional request whose precondition did not hold, not a bad body. **415 Unsupported Media Type** is the right answer when you cannot handle the content type at all, and that decision precedes validation. ## Whichever you choose, the body carries the value The status code has room for exactly one bit of information here. The per-field violation array is what makes the response useful, and its shape must not depend on which of 400 or 422 you landed on - a client should parse the same body either way.
- Where does 409 Conflict fit relative to 400 and 422?409 is about the state of the target resource, not the shape of the request. A duplicate email that violates a uniqueness constraint, or a write against a version that has since moved on, is a conflict with current state and reads naturally as 409. A negative quantity is wrong no matter what is stored, so it is a validation failure, not a conflict.
- A field is missing entirely from the JSON body. Is that 400 or 422 under your rule?Under a parse-versus-rule split it is 422, because the document parsed successfully and it is a schema rule that says the property is required. Some teams call schema conformance part of parsing and answer 400. Either is fine as long as the same choice holds for every endpoint and the violation array names the missing field.
saying these in an interview costs you the question
- Claiming 422 is not real HTTP or is WebDAV-only - RFC 9110 defines it in core
- Using 500 for a rejected input because an exception escaped the handler
- Mixing 400 and 422 for the same class of failure across endpoints
- Using 409 or 404 to signal a bad field value