Why Handling different HTTP methods in Django? - Purpose & Use Cases

The Big Idea

Discover how to stop messy code and make your web app handle requests like a pro!

The Scenario

Imagine building a web app where you must check if a request is GET, POST, or DELETE by hand, then write separate code blocks for each inside one big function.

The Problem

Manually checking HTTP methods leads to messy, hard-to-read code. It's easy to forget a case or mix logic, causing bugs and making updates painful.

The Solution

Django lets you handle different HTTP methods cleanly by defining methods like get() and post() in your views, keeping code organized and clear.

Before vs After

✗ Before

def view(request):
    if request.method == 'GET':
        # handle GET
    elif request.method == 'POST':
        # handle POST

✓ After

from django.views import View

class MyView(View):
    def get(self, request):
        # handle GET
    def post(self, request):
        # handle POST

What It Enables

This makes your web app easier to maintain and extend, letting you focus on what each method should do without tangled checks.

Real Life Example

Think of a blog where GET shows posts, POST adds a new post, and DELETE removes one. Handling these methods cleanly keeps your code neat and your app reliable.

Key Takeaways

Manual HTTP method checks clutter code and cause bugs.

Django's method-based views organize logic by HTTP method.

Clear separation improves maintainability and readability.

Practice

1. In Django, which attribute of the request object helps you determine if the HTTP method is GET or POST inside a view?

easy

A. request.method

B. request.type

C. request.http_method

D. request.action

Solution

1. Step 1: Understand the request object in Django views

   The request object contains details about the HTTP request, including the method used.

2. Step 2: Identify the correct attribute for HTTP method

   The attribute request.method holds the HTTP method as a string like 'GET' or 'POST'.

3. Final Answer:

   request.method -> Option A

4. Quick Check:

   Check HTTP method with request.method [OK]

Hint: Use request.method to check HTTP method type [OK]

Common Mistakes:

• Using request.type instead of request.method
• Trying to access request.http_method which doesn't exist
• Confusing request.action with HTTP method

2. Which of the following is the correct way to restrict a Django view to only accept GET and POST requests using a decorator?

easy

A. @http_methods_only(["GET", "POST"])

B. @allow_methods("GET", "POST")

C. @accept_methods(["GET", "POST"])

D. @require_http_methods(["GET", "POST"])

Solution

1. Step 1: Recall Django's built-in decorators for HTTP methods

   Django provides @require_http_methods to restrict allowed HTTP methods on views.

2. Step 2: Check correct syntax for the decorator

   The decorator takes a list of allowed methods as strings, e.g., ["GET", "POST"].

3. Final Answer:

   @require_http_methods(["GET", "POST"]) -> Option D

4. Quick Check:

   Use @require_http_methods([...]) to restrict methods [OK]

Hint: Use @require_http_methods([...]) to limit HTTP methods [OK]

Common Mistakes:

• Using non-existent decorators like @allow_methods
• Passing methods as separate arguments instead of a list
• Misspelling the decorator name

3. What will be the output of the following Django view when accessed with a POST request?

from django.http import HttpResponse

def my_view(request):
    if request.method == 'GET':
        return HttpResponse('This is a GET request')
    elif request.method == 'POST':
        return HttpResponse('This is a POST request')

medium

A. This is a GET request

B. This is a POST request

C. Error: Method not allowed

D. No response returned

Solution

1. Step 1: Analyze the request method check

   The view checks if request.method is 'GET' or 'POST' and returns corresponding responses.

2. Step 2: Determine response for POST request

   Since the request is POST, the view returns 'This is a POST request' wrapped in an HttpResponse.

3. Final Answer:

   This is a POST request -> Option B

4. Quick Check:

   POST request returns 'This is a POST request' [OK]

Hint: Match request.method to response text [OK]

Common Mistakes:

• Assuming GET response for POST requests
• Expecting an error without decorator
• Missing return statement for POST branch

4. Identify the error in this Django view that tries to handle GET and POST methods:

def example_view(request):
    if request.method = 'GET':
        return HttpResponse('GET request')
    elif request.method == 'POST':
        return HttpResponse('POST request')

medium

A. Using single equals (=) instead of double equals (==) in the if condition

B. Missing import of HttpResponse

C. No return statement for other methods

D. Using elif instead of else

Solution

1. Step 1: Check the if condition syntax

   The condition uses request.method = 'GET' which is an assignment, not a comparison.

2. Step 2: Correct the comparison operator

   It should use == to compare values, like request.method == 'GET'.

3. Final Answer:

   Using single equals (=) instead of double equals (==) in the if condition -> Option A

4. Quick Check:

   Use == for comparison, not = [OK]

Hint: Use == to compare, not = [OK]

Common Mistakes:

• Confusing assignment (=) with comparison (==)
• Forgetting to import HttpResponse (though not asked here)
• Assuming elif must be else

5. You want a Django view to accept only POST requests and return a 405 error for others. Which is the best way to implement this behavior?

hard

A. Check request.method inside the view and return 405 manually

B. Use @csrf_exempt decorator to allow POST only

C. Use @require_http_methods(["POST"]) decorator on the view

D. Raise Http404 if method is not POST

Solution

1. Step 1: Understand Django's method restriction decorators

   The @require_http_methods decorator automatically restricts allowed HTTP methods and returns 405 if not allowed.

2. Step 2: Compare manual checking vs decorator

   While manual checking is possible, the decorator is cleaner, less error-prone, and standard practice.

3. Step 3: Evaluate other options

   @csrf_exempt is unrelated to method restriction; raising Http404 is incorrect for method errors.

4. Final Answer:

   Use @require_http_methods(["POST"]) decorator on the view -> Option C

5. Quick Check:

   Use @require_http_methods to restrict methods cleanly [OK]

Hint: Use @require_http_methods(["POST"]) to restrict POST only [OK]

Common Mistakes:

• Using @csrf_exempt to control HTTP methods
• Raising Http404 instead of 405 for wrong methods
• Manually coding method checks instead of decorator