In Django’s architecture, routing mechanisms direct incoming traffic to specific processing units known as views. A view is a callable responsible for interpreting an HttpRequest, executing application logic, and returning an HttpResponse. These components define how a web application reacts to client interactions and are conventionally stored within views.py. Django offers two architectural patterns for implementing request handlers: Function-Based Views (FBV) and Class-Based Views (CBV).

Implementing Function-Based Views

FBVs rely on standard Python functions. Each function accepts a single request argument and must return a valid response object. To register a function as a route target, the URL configuration must import and reference it directly.

# project/urls.py
from django.urls import path
from catalog.views import product_catalog

urlpatterns = [
    path("catalog/", product_catalog),
]

# catalog/views.py
from django.http import HttpResponse

def product_catalog(request):
    return HttpResponse("Catalog system is online.")

Accessing /catalog/ triggers the function and returns the plain text payload.

Implementing Class-Based Views

CBVs encapsulate request handling logic within Python classes. This pattern promotes code reuse and separates concerns by mapping HTTP verbs to specific class methods. To integrate a CBV into the routing system, the as_view() method must be called, which generates a callable wrapper compatible with Django’s URL dispatcher.

# project/urls.py
from django.urls import path
from catalog.views import ProductCatalogView

urlpatterns = [
    path("catalog/", ProductCatalogView.as_view()),
]

# catalog/views.py
from django.http import HttpResponse
from django.views import View

class ProductCatalogView(View):
    def get(self, request):
        return HttpResponse("Welcome to the product catalog.")

The as_view() wrapper is mandatory because the URL router expects functions, not class definitions. Inheriting from django.views.View grants access to built-in HTTP method dispatchers (get, post, put, delete, etc.), allowing developers to override only the relevant handlers.

Processing HTTP Methods

Client-server communication relies on standardized HTTP verbs. Djengo packages metadata like headers and query parameters into an HttpRequest object passed as the first argument to every view. Determining the request type allows conditional response generation.

In an FBV, the request.method attribute dictates execution flow:

# catalog/views.py
from django.http import HttpResponse

def product_catalog(request):
    if request.method == "GET":
        return HttpResponse("Data retrieval successful.")
    if request.method == "POST":
        return HttpResponse("Resource created successfully.")
    return HttpResponse("Method not supported.", status=405)

Testing state-changing requests (POST, PUT, DELETE) against a running development server often yields a 403 Forbidden error. This behavior stems from Django’s built-in Cross-Site Request Forgery (CSRF) protection, which validates tokens for unsafe methods. To bypass this during API testing, two approaches exist:

1. Global Middleware Disabling: Remove or comment out the CSRF middleware in settings.py.

# settings.py
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    # "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
]

2. View-Level Exemption: Apply the csrf_exempt decorator to isolate the bypass to specific endpoints without compromising global security.

# catalog/views.py
from django.http import HttpResponse
from django.views.decorators.csrf import csrf_exempt

@csrf_exempt
def product_catalog(request):
    if request.method == "POST":
        return HttpResponse("POST request accepted without CSRF validation.")
    return HttpResponse("Awaiting input.")

CBVs streamline verb handling by eliminating conditional statements. Each HTTP method maps directly to a class attribute function:

# catalog/views.py
from django.http import HttpResponse
from django.views import View

class ProductCatalogView(View):
    def get(self, request):
        return HttpResponse("Catalog query processed via GET.")
    
    def post(self, request):
        return HttpResponse("New catalog entry submitted via POST.")

Constructing Different Response Types

Returning raw strings is functional for debugging but impractical for production interfaces. Django supports rendering structured HTML and serializing data into JSON.

Inline HTML generation is possible but tightly couples presentation with logic:

# catalog/views.py
from django.http import HttpResponse

def render_dashboard(request):
    markup = "<h1>System Dashboard</h1><p>Operational status: Nominal</p>"
    return HttpResponse(markup)

Maintaining markup in dedicated .html files via the templating engine is recommended for scalability.

Modern architectures frequently decouple the frontend from backend logic, requiring structured data exchange. The JsonResponse class automatically serializes Python dictionaries and sets the Content-Type header to application/json.

# catalog/views.py
from django.http import JsonResponse

def fetch_catalog_status(request):
    payload = {
        "service_name": "Inventory Tracker",
        "version": "2.1.0",
        "is_active": True
    }
    return JsonResponse(payload)

By default, JsonResponse escapes non-ASCII characters. To preserve unicode text, configure the serialization parameters explicitly:

# catalog/views.py
from django.http import JsonResponse

def fetch_catalog_status(request):
    payload = {
        "service_name": "Inventory Tracker",
        "message": "欢迎使用库存系统",
        "status": "running"
    }
    return JsonResponse(payload, json_dumps_params={"ensure_ascii": False})