422 Unprocessable Entity in Rest API - Step-by-Step Execution

Concept Flow - 422 Unprocessable Entity

Client sends HTTP request

↓

Server receives request

↓

Server validates request data

↓

Data valid

↓

Process request

↓

Return success

The server checks the request data. If data is invalid but syntax is correct, it returns 422 Unprocessable Entity error.

Execution Sample

Rest API

POST /users HTTP/1.1
Content-Type: application/json

{"email": "not-an-email"}

Client sends a POST request with invalid email format in JSON body.

Execution Table

Step	Action	Request Data	Validation Result	Server Response
1	Receive request	{"email": "not-an-email"}	Not validated yet	None
2	Validate email format	{"email": "not-an-email"}	Invalid email format	Prepare 422 response
3	Send response	{"email": "not-an-email"}	Invalid email format	422 Unprocessable Entity

💡 Validation failed due to invalid email format, so server returns 422 error.

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
request_data	None	{"email": "not-an-email"}	{"email": "not-an-email"}	{"email": "not-an-email"}
validation_result	None	None	Invalid email format	Invalid email format
server_response	None	None	Prepare 422 response	422 Unprocessable Entity

Key Moments - 2 Insights

Why does the server return 422 instead of 400 Bad Request?

422 means the request syntax is correct but the data is invalid. 400 is for malformed syntax. See execution_table step 2 where validation fails but request is syntactically valid.

Can the server process the request if it returns 422?

No, the server cannot process invalid data. It stops and returns 422 as shown in execution_table step 3.

Visual Quiz - 3 Questions

Look at the execution_table, what is the validation result at step 2?

A Valid data

B Invalid email format

C Syntax error

D No validation done

💡 Hint

Check the 'Validation Result' column at step 2 in execution_table.

At which step does the server send the 422 response?

A Step 1

B Step 2

C Step 3

D No 422 response sent

💡 Hint

Look at the 'Server Response' column in execution_table.

If the email was valid, how would the server_response variable change after step 3?

A It would be a success response

B It would be None

C It would be 422 Unprocessable Entity

D It would be a 400 Bad Request

💡 Hint

Refer to variable_tracker for server_response variable and think about valid data processing.

Concept Snapshot

422 Unprocessable Entity means the server understands the request syntax but the data is invalid.
Used when request body has correct format but fails validation.
Server responds with status 422 and error details.
Client should fix data and resend.
Different from 400 Bad Request which means syntax error.

Full Transcript

When a client sends a request to a server, the server first checks if the request is correctly formed. If the syntax is correct but the data inside is invalid, the server returns a 422 Unprocessable Entity error. For example, if an email field is not a valid email format, the server will reject it with 422. This means the client must fix the data before trying again. The server does not process invalid data. This is different from a 400 Bad Request, which means the request syntax itself is wrong. The 422 status helps clients understand that the request was understood but the content is wrong.

Practice

1. What does the HTTP status code 422 Unprocessable Entity indicate in a REST API?

easy

A. The server encountered an unexpected error.

B. The server understands the request but the data is invalid or incomplete.

C. The requested resource was not found on the server.

D. The client is not authorized to access the resource.

Solution

1. Step 1: Understand HTTP status codes

   HTTP status codes communicate the result of a client's request to the server.

2. Step 2: Identify the meaning of 422

   422 means the server understood the request but the data sent is invalid or incomplete, so it cannot process it.

3. Final Answer:

   The server understands the request but the data is invalid or incomplete. -> Option B

4. Quick Check:

   422 = invalid or incomplete data [OK]

Hint: 422 means data is wrong but request format is correct [OK]

Common Mistakes:

• Confusing 422 with 404 Not Found
• Thinking 422 means server error
• Assuming 422 means unauthorized access

2. Which of the following is the correct way to respond with a 422 status code in a REST API using Express.js (Node.js)?

easy

A. res.sendStatus(404);

B. res.status(200).json({ message: 'Success' });

C. res.status(500).json({ error: 'Server error' });

D. res.status(422).send('Invalid input data');

Solution

1. Step 1: Identify correct status code usage

   To send a 422 status, use res.status(422) in Express.js.

2. Step 2: Confirm response method

   Using .send() or .json() after setting status sends the response properly.

3. Final Answer:

   res.status(422).send('Invalid input data'); -> Option D

4. Quick Check:

   Express 422 response = res.status(422).send() [OK]

Hint: Use res.status(422) to set code before sending response [OK]

Common Mistakes:

• Using wrong status code like 404 or 500
• Forgetting to set status before sending response
• Sending 200 OK for invalid data

3. Consider this JSON response from a REST API:

{
  "status": 422,
  "errors": {
    "email": "Invalid email format",
    "password": "Password too short"
  }
}

What does this response tell the client?

medium

A. The server could not process the request because the email and password fields are invalid.

B. The server processed the request successfully with no errors.

C. The server is down and cannot handle requests.

D. The client is not authorized to access this resource.

Solution

1. Step 1: Analyze the status code

   Status 422 means the server understood the request but found invalid data.

2. Step 2: Interpret the errors object

   The errors show specific problems: invalid email format and password too short.

3. Final Answer:

   The server could not process the request because the email and password fields are invalid. -> Option A

4. Quick Check:

   422 + errors = invalid input fields [OK]

Hint: 422 with errors means input fields have problems [OK]

Common Mistakes:

• Thinking 422 means server failure
• Ignoring the errors object details
• Assuming success when status is 422

4. You wrote this code snippet in a REST API controller:

if (!user.email.includes('@')) {
  res.status(422).json({ error: 'Invalid email' });
}
// further processing

But clients report they still get 200 OK even with invalid emails. What is the likely bug?

medium

A. The client is ignoring the 422 status code.

B. The status code 422 is not supported by REST APIs.

C. The function does not return after sending the 422 response, so processing continues.

D. The email validation logic is correct, so the bug is elsewhere.

Solution

1. Step 1: Check response flow

   After sending a response, the function must stop further processing to avoid sending another response.

2. Step 2: Identify missing return

   If return is missing before res.status(422)..., the code continues and may send 200 OK later.

3. Final Answer:

   The function does not return after sending the 422 response, so processing continues. -> Option C

4. Quick Check:

   Return after res.status(422) to stop processing [OK]

Hint: Always return after sending 422 response to stop code [OK]

Common Mistakes:

• Not returning after sending response
• Misunderstanding 422 support in REST
• Blaming client instead of server code

5. You are designing a REST API endpoint for user registration. Which approach best uses the 422 status code to improve client communication when input data is invalid?

hard

A. Return 422 with a JSON object listing each invalid field and a clear error message.

B. Return 422 with a generic message: 'Invalid data'.

C. Return 400 Bad Request without details about the errors.

D. Return 200 OK and ignore invalid fields silently.

Solution

1. Step 1: Understand purpose of 422

   422 is used to tell clients exactly what data is invalid to help fix input.

2. Step 2: Choose detailed error reporting

   Providing a JSON object with each invalid field and message improves client experience.

3. Final Answer:

   Return 422 with a JSON object listing each invalid field and a clear error message. -> Option A

4. Quick Check:

   422 + detailed errors = better client feedback [OK]

Hint: Use 422 with detailed errors for clear client feedback [OK]

Common Mistakes:

• Sending vague error messages
• Using wrong status codes like 400 or 200
• Not informing client about specific invalid fields