Atunci când deschizi o pagină, browserul și serverul poartă o conversație bine structurată. Browserul trimite o cerere HTTP, aplicația identifică operația cerută, execută logica necesară și întoarce un răspuns HTTP. Înțelegerea acestui traseu te ajută să depanezi erori, să proiectezi funcții mai clare și să separi responsabilitățile unei aplicații.
Modelul de bază: request → route → view → response
HTTP este protocolul prin care un client, de regulă browserul, cere o resursă unui server. Cererea conține o metodă precum GET sau POST, o adresă, antete și uneori date. Răspunsul conține un cod de stare, antete și, de cele mai multe ori, un corp HTML sau JSON.
- Request: browserul cere o adresă, de exemplu
/proiecte/7/. - Route: aplicația compară adresa cu regulile URL definite de dezvoltator.
- View: funcția sau clasa asociată validează intrarea și decide ce trebuie executat.
- Data: dacă este necesar, view-ul citește sau scrie date prin model.
- Response: aplicația întoarce o pagină, date JSON, o redirecționare sau o eroare explicită.
Documentația oficială descrie HTTP drept un protocol client–server, iar documentația Django arată aceeași limită în cod: framework-ul primește un obiect HttpRequest și așteaptă un HttpResponse. Acesta este contractul central al unei aplicații web.
Un exemplu Django minimal
Să presupunem că vrem o pagină publică pentru un proiect. Mai întâi definim ruta:
# urls.py
from django.urls import path
from . import views
urlpatterns = [
path("proiecte/<int:project_id>/", views.project_detail),
]Segmentul <int:project_id> acceptă un număr întreg și îl transmite view-ului. Apoi implementăm răspunsul:
# views.py
from django.shortcuts import get_object_or_404, render
from .models import Project
def project_detail(request, project_id):
project = get_object_or_404(
Project,
pk=project_id,
is_public=True,
)
return render(request, "projects/detail.html", {"project": project})View-ul nu presupune că proiectul există și nici că este public. get_object_or_404 întoarce obiectul potrivit sau produce un răspuns 404. Șablonul primește numai datele pe care trebuie să le prezinte:
<article>
<h1>{{ project.title }}</h1>
<p>{{ project.summary }}</p>
</article>Exemplul este mic, dar conține întregul traseu: URL-ul extrage identificatorul, view-ul aplică regula de acces, modelul furnizează datele, iar template-ul produce HTML-ul.
Ce înseamnă metodele și codurile de stare
Metoda trebuie să exprime intenția cererii. GET citește o resursă și nu ar trebui folosit pentru o schimbare de stare. POST transmite de obicei date pentru o operație care poate modifica starea. Într-o aplicație reală vei întâlni și PUT, PATCH sau DELETE, mai ales în API-uri.
Codul de stare spune clientului ce s-a întâmplat:
200 OK— cererea a fost procesată și resursa este returnată;302 Found— clientul este redirecționat, frecvent după trimiterea reușită a unui formular;400 Bad Request— datele cererii nu respectă contractul așteptat;403 Forbidden— identitatea este cunoscută, dar operația nu este permisă;404 Not Found— resursa nu există sau nu trebuie expusă solicitantului;500 Internal Server Error— aplicația a întâlnit o eroare necontrolată.
Un răspuns corect nu înseamnă întotdeauna 200. Un 404 intenționat este mai bun decât o pagină goală care pretinde că resursa există, iar o validare 400 este mai bună decât acceptarea unor date ambigue.
Formulare, validare și securitate
Datele venite de la utilizator nu sunt de încredere implicit. Aplicația trebuie să valideze tipul, lungimea, formatul și regulile de business înainte de a salva ceva. Autentificarea răspunde la întrebarea „cine este utilizatorul?”, iar autorizarea răspunde la „are voie să execute această operație?”. Sunt verificări diferite.
Pentru cererile care schimbă starea, Django oferă protecție împotriva atacurilor CSRF atunci când mecanismul este configurat și utilizat corect. Framework-ul oferă și protecții pentru alte clase de riscuri, dar ele nu înlocuiesc validarea, autorizarea și gestionarea atentă a datelor. Securitatea este o proprietate a întregului flux, nu o opțiune adăugată la final.
Cum depanezi metodic o cerere
Când o pagină nu funcționează, urmărește traseul în aceeași ordine în care îl parcurge cererea:
- Verifică în instrumentele browserului adresa, metoda, datele trimise și codul primit.
- Confirmă că ruta se potrivește și că parametrii au tipurile așteptate.
- Verifică validarea, autentificarea și autorizarea din view.
- Inspectează interogarea și cazul în care datele nu există.
- Verifică datele oferite template-ului sau structura răspunsului JSON.
- Reproduce cazul printr-un test automat, apoi corectează cauza, nu doar simptomul.
Mesajele de eroare trebuie citite de jos în sus până la prima linie care aparține codului aplicației. Documentația Python explică diferența dintre erorile de sintaxă și excepțiile apărute în timpul execuției; această distincție reduce mult timpul pierdut în depanare.
Exercițiu practic
Construiește o aplicație cu o listă de proiecte și o pagină de detaliu. Adaugă apoi, pe rând:
- un proiect inexistent care trebuie să răspundă cu 404;
- un câmp
is_publiccare ascunde proiectele private; - un formular validat pentru crearea unui proiect;
- o redirecționare după salvare, astfel încât reîncărcarea paginii să nu retrimită formularul;
- teste pentru răspunsul 200, cazul 404 și accesul neautorizat.
Acest exercițiu este mai valoros dacă poți explica fiecare trecere dintre componente, nu doar dacă pagina finală „merge”. Pentru o fundație ghidată în Python poți consulta programul Python Foundations; pentru felul în care structurăm învățarea practică, vezi Metoda Carpathica.