Path operations (GET, POST, PUT, DELETE) in FastAPI - Step-by-Step Execution

Concept Flow - Path operations (GET, POST, PUT, DELETE)

Client sends HTTP request

↓

FastAPI receives request

↓

Match request method and path

↓

GET

↓

Run GET handler

↓

Send response back to client

The server listens for HTTP requests, matches the method and path, runs the correct handler, and sends back a response.

Execution Sample

FastAPI

from fastapi import FastAPI
app = FastAPI()

@app.get("/items/{id}")
def read_item(id: int):
    return {"id": id}

@app.post("/items")
def create_item(item: dict):
    return item

Defines GET and POST path operations for /items with FastAPI.

Execution Table

Step	Request Method	Request Path	Matched Handler	Handler Action	Response
1	GET	/items/5	read_item	Return {'id': 5}	{"id": 5}
2	POST	/items	create_item	Return posted item {'name': 'book'}	{"name": "book"}
3	PUT	/items/5	No match	Return 404 Not Found	404 Not Found
4	DELETE	/items/5	No match	Return 404 Not Found	404 Not Found

💡 Requests with no matching method and path return 404 Not Found.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
request_method	None	GET	POST	PUT	DELETE
request_path	None	/items/5	/items	/items/5	/items/5
matched_handler	None	read_item	create_item	None	None
response	None	{"id": 5}	{"name": "book"}	404 Not Found	404 Not Found

Key Moments - 2 Insights

Why does a PUT request to /items/5 return 404 even though the path looks similar to GET?

Because no handler is defined for PUT method on /items/{id}, only GET and POST exist. See execution_table rows 3 and 4.

How does FastAPI know which function to run for a request?

It matches both the HTTP method (GET, POST, etc.) and the path pattern. Only exact method and path matches run the handler. See execution_table column 'Matched Handler'.

Visual Quiz - 3 Questions

Look at the execution table, what response does the GET request to /items/5 return?

A {"id": 5}

B {"name": "book"}

C 404 Not Found

D Empty response

💡 Hint

Check row 1 in the execution_table under the Response column.

At which step does the request method 'PUT' fail to find a matching handler?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Matched Handler' column for 'PUT' in execution_table.

If we add a @app.put("/items/{id}") handler, how would the response at Step 3 change?

A It would still return 404 Not Found

B It would return the PUT handler's response

C It would return the GET handler's response

D It would cause a server error

💡 Hint

Adding a matching handler for PUT changes matched_handler from None to that handler.

Concept Snapshot

FastAPI path operations handle HTTP methods: GET, POST, PUT, DELETE.
Define handlers with decorators @app.get(), @app.post(), etc.
Server matches method and path to run correct handler.
No match returns 404 Not Found.
Handlers return JSON responses by default.

Full Transcript

This visual shows how FastAPI handles HTTP requests by matching the method and path to the correct function. When a client sends a GET request to /items/5, FastAPI runs the read_item function and returns the item id. A POST to /items runs create_item and returns the posted data. PUT and DELETE requests without handlers return 404 errors. Variables like request_method and matched_handler change as requests are processed. Understanding this flow helps beginners see how web APIs respond differently based on HTTP methods.

Practice

1. Which HTTP method in FastAPI is typically used to retrieve data without changing anything on the server?

easy

A. DELETE

B. POST

C. PUT

D. GET

Solution

1. Step 1: Understand HTTP methods purpose

   GET is used to read or retrieve data without modifying it.

2. Step 2: Match method to FastAPI operation

   FastAPI uses @app.get() decorator for GET requests to fetch data.

3. Final Answer:

   GET -> Option D

4. Quick Check:

   GET = Read data [OK]

Hint: GET always fetches data without side effects [OK]

Common Mistakes:

• Confusing GET with POST which creates data
• Using PUT for reading data
• Thinking DELETE retrieves data

2. Which of the following is the correct syntax to define a POST path operation in FastAPI to create a new item?

easy

A. @app.post('/items/')\ndef create_item(): pass

B. @app.get('/items/')\ndef create_item(): pass

C. @app.put('/items/')\ndef create_item(): pass

D. @app.delete('/items/')\ndef create_item(): pass

Solution

1. Step 1: Identify the HTTP method for creating data

   POST is used to create new resources in REST APIs.

2. Step 2: Match FastAPI decorator for POST

   FastAPI uses @app.post() decorator to handle POST requests.

3. Final Answer:

   @app.post('/items/')\ndef create_item(): pass -> Option A

4. Quick Check:

   POST = Create data [OK]

Hint: Use @app.post() for creating new data [OK]

Common Mistakes:

• Using @app.get() for creating data
• Confusing PUT with POST
• Using DELETE for creation

3. What will be the response when this FastAPI code is called with a PUT request to update item with id 5?

from fastapi import FastAPI
app = FastAPI()

items = {5: "old value"}

@app.put('/items/{item_id}')
async def update_item(item_id: int):
    items[item_id] = "new value"
    return items[item_id]

medium

A. "new value"

B. "old value"

C. KeyError

D. None

Solution

1. Step 1: Understand the PUT operation code

   The function updates the dictionary value for the given item_id to "new value".

2. Step 2: Check the returned value

   The function returns the updated value, which is "new value".

3. Final Answer:

   "new value" -> Option A

4. Quick Check:

   PUT updates and returns new value [OK]

Hint: PUT replaces existing data and returns updated value [OK]

Common Mistakes:

• Expecting old value after update
• Thinking KeyError occurs without check
• Assuming None is returned

4. Identify the error in this FastAPI DELETE operation code:

from fastapi import FastAPI
app = FastAPI()

items = {1: "apple", 2: "banana"}

@app.delete('/items/{item_id}')
async def delete_item(item_id: int):
    del items[item_id]
    return {"message": "Item deleted"}

medium

A. Missing return statement

B. Wrong HTTP method decorator

C. Deleting item without checking if it exists

D. Function should not be async

Solution

1. Step 1: Analyze the delete operation

   The code deletes an item by key without verifying if the key exists in the dictionary.

2. Step 2: Understand possible runtime error

   If the item_id does not exist, del will raise a KeyError causing a server error.

3. Final Answer:

   Deleting item without checking if it exists -> Option C

4. Quick Check:

   Delete needs existence check [OK]

Hint: Always check if item exists before deleting [OK]

Common Mistakes:

• Assuming item always exists
• Ignoring KeyError on delete
• Thinking async is wrong here

5. You want to create a FastAPI app that supports all four main HTTP methods (GET, POST, PUT, DELETE) for managing a list of users stored in a dictionary. Which approach correctly handles updating a user only if it exists, creating a new user, retrieving a user by ID, and deleting a user safely?

hard

A. Use @app.get to retrieve, @app.post to create, @app.put to update without checking existence, and @app.delete to delete without checking existence

B. Use @app.get to retrieve, @app.post to create, @app.put to update with existence check, and @app.delete to delete with existence check

C. Use only @app.post for all operations to simplify code

D. Use @app.put to create and update, @app.get to delete, @app.post to retrieve

Solution

1. Step 1: Match HTTP methods to CRUD operations

   GET retrieves, POST creates, PUT updates, DELETE removes resources.

2. Step 2: Ensure safe update and delete

   Update and delete should check if the user exists to avoid errors.

3. Final Answer:

   Use @app.get to retrieve, @app.post to create, @app.put to update with existence check, and @app.delete to delete with existence check -> Option B

4. Quick Check:

   Correct HTTP methods with safety checks [OK]

Hint: Match HTTP verbs to actions and check existence before update/delete [OK]

Common Mistakes:

• Skipping existence checks causing errors
• Using wrong HTTP methods for actions
• Trying to do all actions with one method