Why HTTP methods define intent in Rest API - Performance Analysis
When working with HTTP methods, it's important to understand how the server handles each request type.
We want to see how the server's work grows as requests increase, based on the method's intent.
Analyze the time complexity of handling different HTTP methods in a REST API.
@app.route('/items', methods=['GET', 'POST', 'PUT', 'DELETE'])
def items():
if request.method == 'GET':
return get_all_items()
elif request.method == 'POST':
return create_item(request.data)
elif request.method == 'PUT':
return update_item(request.data)
elif request.method == 'DELETE':
return delete_item(request.data)
This code handles different HTTP methods to get, create, update, or delete items.
Look at what repeats when the server processes requests.
- Primary operation: Iterating over items for GET or searching for the item to update/delete.
- How many times: Depends on the number of items stored (n).
As the number of items grows, the server work changes depending on the method.
| Input Size (n) | Approx. Operations for GET |
|---|---|
| 10 | 10 operations (checking each item) |
| 100 | 100 operations |
| 1000 | 1000 operations |
For GET, work grows linearly with the number of items. For POST, work is usually constant since it adds one item. PUT and DELETE may also grow linearly if searching is needed.
Time Complexity: O(n)
This means the server's work grows in direct proportion to the number of items when handling GET, PUT, or DELETE requests.
[X] Wrong: "All HTTP methods take the same time regardless of data size."
[OK] Correct: Some methods like GET or DELETE may need to look through many items, so their time grows with data size.
Understanding how HTTP methods affect server work helps you explain API design choices clearly and confidently.
"What if the server used an index to find items for PUT and DELETE? How would that change the time complexity?"
Practice
Solution
Step 1: Understand the purpose of HTTP methods
GET is designed to request data without modifying it, making it safe and idempotent.Step 2: Match method to action
Since the question asks for retrieving data without changes, GET fits perfectly.Final Answer:
GET -> Option AQuick Check:
Retrieve data = GET [OK]
- Confusing GET with POST
- Thinking DELETE retrieves data
- Using PUT to fetch data
Solution
Step 1: Identify the method used for updating
PUT is the HTTP method used to update or replace a resource at a specific URL.Step 2: Check the syntax correctness
PUT /resource/123 correctly targets the resource with ID 123 for update.Final Answer:
PUT /resource/123 -> Option DQuick Check:
Update resource = PUT [OK]
- Using GET to update
- POST is for creating, not updating
- DELETE removes, not updates
POST /users
{
"name": "Alice",
"age": 30
}Solution
Step 1: Identify the HTTP method used
POST is used to create new resources on the server.Step 2: Analyze the request body
The JSON data contains user details, indicating creation of a new user named Alice.Final Answer:
Create a new user named Alice -> Option AQuick Check:
POST with data = Create new resource [OK]
- Thinking POST retrieves data
- Confusing POST with PUT for update
- Assuming POST deletes data
POST /users/45 is not working. What is the correct method to use?Solution
Step 1: Understand the intent of the request
The goal is to remove (delete) a user, so the method must express deletion.Step 2: Choose the HTTP method for deletion
DELETE is the standard method to remove a resource identified by a URL.Final Answer:
DELETE -> Option CQuick Check:
Remove resource = DELETE [OK]
- Using POST to delete
- Confusing PATCH with DELETE
- Trying GET to remove data
PATCH /profile/123 updates only the email field of a user profile, while PUT /profile/123 replaces the entire profile. Why is it important to choose PATCH over PUT when updating just one field?Solution
Step 1: Understand the difference between PUT and PATCH
PUT replaces the entire resource, so missing fields get erased. PATCH updates only specified fields.Step 2: Analyze the risk of using PUT for partial updates
If you use PUT but omit some fields, those fields may be removed unintentionally.Final Answer:
PUT can accidentally erase other fields if not included -> Option BQuick Check:
Partial update safe = PATCH, full replace risk = PUT [OK]
- Thinking PATCH creates new resource
- Believing PUT only deletes
- Assuming PATCH sends no data
Ready to prove it?
Pass the test and this pattern moves unknown
