The HTTP status code 422 represents “Unprocessable Entity.” This status code was initially defined in the WebDAV (Web Distributed Authoring and Versioning) extension but is now widely used in many other HTTP applications.
Definition
- The 422 status code indicates that the server understands the content type of the request entity, and the request syntax is correct, but the server is unable to process the contained instructions.
Use Cases
- Data Validation Failure: When submitted data does not comply with business rules.
- Semantic Errors: The request format is correct, but there are semantic errors.
- Dependency Issues: The operation requested depends on other conditions that have not been met.
Distinction from Other Status Codes
- Unlike 400 (Bad Request), the 422 status code indicates that the request syntax is correct but has semantic errors.
- Unlike 415 (Unsupported Media Type), 422 means the content type is correct, but the content itself has issues.
Common Applications
- RESTful APIs: To indicate that the request data does not meet the processing requirements of the API.
- Form Submissions: When form data is formatted correctly but does not comply with business logic.
Example Scenario
app.post("/api/register", (req, res) => {
const { username, email, password } = req.body;
// Validate input
if (!username || username.length < 3) {
return res.status(422).json({
error: "Unprocessable Entity",
message: "Username must be at least 3 characters long",
});
}
if (!email || !email.includes("@")) {
return res.status(422).json({
error: "Unprocessable Entity",
message: "Invalid email format",
});
}
if (!password || password.length < 8) {
return res.status(422).json({
error: "Unprocessable Entity",
message: "Password must be at least 8 characters long",
});
}
// If all validations pass, proceed with registration
// ... registration logic here ...
res.status(201).json({ message: "User registered successfully" });
});
Example Scenario
In this example, if the username, email, or password does not meet the requirements, the API would return a 422 status code along with specific error messages.
Client Handling
Upon receiving a 422 response, the client should:
- Check the submitted data and correct errors.
- Display specific error messages to users, guiding them on how to fix their input.
- Avoid automatically retrying the request, as resending the same data may lead to the same errors.
Best Practices
- The server should provide detailed error messages in the response body, explaining which fields have issues and how to correct them.
- Use a structured error response format, such as JSON, for easier client parsing and handling.
- Clearly document in the API documentation the conditions that may lead to a 422 error.
Security Considerations
While it is important to provide useful error messages, care should be taken not to disclose sensitive information or system details.
Original Use in WebDAV
In WebDAV, a 422 status code might be used to indicate that the requested method cannot be performed on the resource, even if the request itself is valid.
The 422 status code is highly useful in modern web development, especially when building RESTful APIs. It allows the server to explicitly indicate that the request data is semantically invalid, rather than just format-related issues, facilitating clear communication between client and server.
Related 4xx error code
- 400 Bad Request
- 401 Unauthorized
- 402 Payment Required
- 403 Forbidden
- 404 Not Found
- 405 Method Not Allowed
- 406 Not Acceptable
- 407 Proxy Authentication Required
- 408 Request Timeout
- 409 Conflict
- 410 Gone
- 411 Length Required
- 412 Precondition Failed
- 413 Payload Too Large
- 414 URI Too Long
- 415 Unsupported Media Type
- 416 Range Not Satisfiable
- 417 Expectation Failed
- 418 I’m a teapot
- 421 Misdirected Request
- 423 Locked (WebDAV)
- 424 Failed Dependency (WebDAV)
- 425 Too Early
- 426 Upgrade Required
- 428 Precondition Required
- 429 Too Many Requests
- 431 Request Header Fields Too Large
- 451 Unavailable For Legal Reasons
- 499 Client Closed Request