404 Not Found in Rest API - Step-by-Step Execution

Concept Flow - 404 Not Found

Client sends HTTP request

↓

Server receives request

↓

Check if resource exists

↓

Return resource

↓

Client receives response

The client sends a request; the server checks if the resource exists. If not, it returns a 404 Not Found response.

Execution Sample

Rest API

GET /api/users/123 HTTP/1.1
Host: example.com

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

{"error":"User not found"}

A client requests a user that does not exist; the server responds with 404 Not Found and an error message.

Execution Table

Step	Action	Resource Exists?	Response Status	Response Body
1	Client sends GET /api/users/123	Unknown	Waiting	None
2	Server checks resource	No	Determined	None
3	Server sends response	No	404 Not Found	{"error":"User not found"}
4	Client receives response	No	404 Not Found	{"error":"User not found"}

💡 Resource does not exist, so server returns 404 Not Found response.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
resource_exists	Unknown	Unknown	No	No	No
response_status	None	Waiting	Determined	404 Not Found	404 Not Found
response_body	None	None	None	{"error":"User not found"}	{"error":"User not found"}

Key Moments - 2 Insights

Why does the server return 404 Not Found instead of the requested data?

Because the server checked and found that the requested resource does not exist, as shown in step 2 and 3 of the execution table.

Is 404 Not Found an error in the client request or server problem?

404 Not Found means the client requested something that isn't there; it's not a server error but a missing resource, as seen in the response status in step 3.

Visual Quiz - 3 Questions

Look at the execution table, what is the response status at step 3?

A 200 OK

B 404 Not Found

C 500 Internal Server Error

D 301 Moved Permanently

💡 Hint

Check the 'Response Status' column at step 3 in the execution table.

At which step does the server determine the resource does not exist?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Resource Exists?' column in the execution table.

If the resource existed, how would the response status change in the table?

A It would change to 200 OK

B It would change to 500 Internal Server Error

C It would stay 404 Not Found

D It would be 301 Moved Permanently

💡 Hint

Think about what status code means success versus not found.

Concept Snapshot

404 Not Found:
- HTTP status code meaning resource not found
- Server checks if resource exists
- If missing, returns 404 with error message
- Client receives 404 and knows resource is missing
- Common in REST APIs for invalid URLs or IDs

Full Transcript

When a client sends a request to a server, the server checks if the requested resource exists. If it does not, the server responds with a 404 Not Found status code and an error message. This tells the client that the resource is missing, not that the server failed. The client can then handle this response appropriately, such as showing a 'not found' message to the user.

Practice

1. What does the HTTP status code 404 Not Found indicate in a REST API?

easy

A. The requested resource does not exist on the server.

B. The server has encountered an internal error.

C. The request was successful and data is returned.

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 meaning of 404

   404 means the server cannot find the requested resource or URL.

3. Final Answer:

   The requested resource does not exist on the server. -> Option A

4. Quick Check:

   404 = Resource not found [OK]

Hint: 404 means resource missing, not server error [OK]

Common Mistakes:

• Confusing 404 with 500 internal server error
• Thinking 404 means unauthorized access
• Assuming 404 means request succeeded

2. Which of the following is the correct way to send a 404 Not Found response in a REST API using HTTP headers?

easy

A. HTTP/1.1 403 Forbidden\r\nContent-Type: application/json\r\n\r\n

B. HTTP/1.1 200 OK\r\nContent-Type: application/json\r\n\r\n

C. HTTP/1.1 404 Not Found\r\nContent-Type: application/json\r\n\r\n

D. HTTP/1.1 500 Internal Server Error\r\nContent-Type: text/html\r\n\r\n

Solution

1. Step 1: Identify correct HTTP status line for 404

   The status line must start with HTTP version and '404 Not Found' to indicate missing resource.

2. Step 2: Check headers format

   Headers like Content-Type follow the status line, separated by CRLF, then a blank line before body.

3. Final Answer:

   HTTP/1.1 404 Not Found\r\nContent-Type: application/json\r\n\r\n -> Option C

4. Quick Check:

   Status line with 404 and proper headers = HTTP/1.1 404 Not Found\r\nContent-Type: application/json\r\n\r\n [OK]

Hint: 404 response starts with 'HTTP/1.1 404 Not Found' [OK]

Common Mistakes:

• Using 200 OK status for missing resource
• Mixing 404 with 500 or 403 status codes
• Incorrect header formatting or missing blank line

3. Consider this Python Flask code snippet for a REST API endpoint:

from flask import Flask, jsonify, abort
app = Flask(__name__)

@app.route('/items/')
def get_item(item_id):
    items = {1: 'apple', 2: 'banana'}
    if item_id not in items:
        abort(404)
    return jsonify({'item': items[item_id]})

What will be the HTTP status code if a client requests /items/3?

medium

A. 404 Not Found

B. 200 OK

C. 500 Internal Server Error

D. 400 Bad Request

Solution

1. Step 1: Check if item_id 3 exists in items dictionary

   Items only have keys 1 and 2, so 3 is missing.

2. Step 2: Understand abort(404) behavior

   Calling abort(404) sends a 404 Not Found response to the client.

3. Final Answer:

   404 Not Found -> Option A

4. Quick Check:

   Missing item triggers abort(404) = 404 Not Found [OK]

Hint: abort(404) sends 404 status when resource missing [OK]

Common Mistakes:

• Assuming 200 OK even if item missing
• Confusing abort(404) with server error
• Thinking 400 Bad Request applies here

4. You have this Express.js route handler:

app.get('/users/:id', (req, res) => {
  const users = {1: 'Alice', 2: 'Bob'};
  const user = users[req.params.id];
  if (!user) {
    res.status(404);
  }
  res.send(user);
});

What is the problem with this code when a user is not found?

medium

A. It correctly sends a 404 status with no body.

B. It sends a 404 status but still sends undefined as response body.

C. It throws a syntax error due to missing semicolon.

D. It sends a 500 Internal Server Error automatically.

Solution

1. Step 1: Analyze response when user not found

   res.status(404) sets status but does not end response or send body.

2. Step 2: Check what res.send(user) does

   res.status(404) sets the status, but execution continues to res.send(undefined), which sends the string 'undefined' as body with 404 status.

3. Final Answer:

   It sends a 404 status but still sends undefined as response body. -> Option B

4. Quick Check:

   Missing res.send after status causes wrong response [OK]

Hint: Always send response body or end response after setting status [OK]

Common Mistakes:

• Setting status without sending response body
• Assuming status alone ends response
• Not checking for undefined response body

5. You are designing a REST API for a library. When a client requests a book by ID that does not exist, you want to return a 404 Not Found with a helpful JSON message. Which of the following Express.js code snippets correctly implements this behavior?

hard

A. app.get('/books/:id', (req, res) => {
const books = {1: '1984', 2: 'Brave New World'};
const book = books[req.params.id];
if (!book) {
res.sendStatus(404);
}
res.json({book});
});

B. app.get('/books/:id', (req, res) => {
const books = {1: '1984', 2: 'Brave New World'};
const book = books[req.params.id];
if (!book) {
res.json({error: 'Book not found'});
}
res.status(404).json({book});
});

C. app.get('/books/:id', (req, res) => {
const books = {1: '1984', 2: 'Brave New World'};
const book = books[req.params.id];
if (!book) {
res.status(404);
}
res.json({book});
});

D. app.get('/books/:id', (req, res) => {
const books = {1: '1984', 2: 'Brave New World'};
const book = books[req.params.id];
if (!book) {
res.status(404).json({error: 'Book not found'});
return;
}
res.json({book});
});

Solution

1. Step 1: Check how 404 and message are sent

   app.get('/books/:id', (req, res) => { const books = {1: '1984', 2: 'Brave New World'}; const book = books[req.params.id]; if (!book) { res.status(404).json({error: 'Book not found'}); return; } res.json({book}); }); sets status 404 and sends JSON with error message, then returns to avoid sending more.

2. Step 2: Verify other options

   app.get('/books/:id', (req, res) => { const books = {1: '1984', 2: 'Brave New World'}; const book = books[req.params.id]; if (!book) { res.json({error: 'Book not found'}); } res.status(404).json({book}); }); sends JSON without status 404 first, then tries to send 404 with book JSON (wrong order). app.get('/books/:id', (req, res) => { const books = {1: '1984', 2: 'Brave New World'}; const book = books[req.params.id]; if (!book) { res.status(404); } res.json({book}); }); sets status but does not send response properly. app.get('/books/:id', (req, res) => { const books = {1: '1984', 2: 'Brave New World'}; const book = books[req.params.id]; if (!book) { res.sendStatus(404); } res.json({book}); }); sends 404 status but then sends book JSON anyway.

3. Final Answer:

   Sets status(404).json({error: 'Book not found'}); return; to send 404 with helpful JSON message and end response. -> Option D

4. Quick Check:

   Set status, send JSON, and return to end response = app.get('/books/:id', (req, res) => { const books = {1: '1984', 2: 'Brave New World'}; const book = books[req.params.id]; if (!book) { res.status(404).json({error: 'Book not found'}); return; } res.json({book}); }); [OK]

Hint: Set status, send JSON error, and return immediately [OK]

Common Mistakes:

• Not returning after sending 404 response
• Sending response body after status without ending
• Mixing order of status and response methods