REST folosește metodele HTTP standard ca verbe care acționează asupra resurselor. Maparea comună pe CRUD (Create, Read, Update, Delete) este:
REST folosește metodele HTTP standard ca verbe care acționează asupra resurselor. Maparea comună pe CRUD (Create, Read, Update, Delete) este:
| CRUD | Method | Utilizare tipică |
|---|
| Create | POST | Adaugă o resursă nouă într-o colecție |
| Read | GET | Preia o resursă sau o listă |
| Update (complet) | PUT | Înlocuiește complet o resursă |
| Update (parțial) | PATCH | Modifică unele câmpuri |
| Delete | DELETE | Elimină o resursă |
POST /users HTTP/1.1
Content-Type: application/json
{ "name": "Ann", "email": "[email protected]" }
HTTP/1.1 201 Created
Location: /users/42
{ "id": 42, "name": "Ann", "email": "[email protected]" }
PUT /users/42 trimite întreaga reprezentare și o înlocuiește; PATCH /users/42 trimite doar câmpurile de schimbat (ex. { "email": "[email protected]" }).
Acestea sunt două proprietăți diferite:
GET, HEAD, OPTIONS sunt safe.GET, PUT, DELETE, HEAD sunt idempotente.Method Safe? Idempotent?
GET da da
HEAD da da
PUT nu da (înlocuirea cu același body de două ori = același rezultat)
DELETE nu da (ștergere de două ori = tot șters)
PATCH nu nu* (depinde de patch; nu e garantat)
POST nu nu (POST de două ori creează de obicei două resurse)
Intervievatorii întreabă asta pentru a vedea dacă înțelegi semantica HTTP suficient de bine pentru a construi API-uri fiabile. Distincția safe/idempotent nu este academică: guvernează direct ce au voie să facă clienții, proxy-urile și CDN-urile. Metodele safe pot fi cache-uite și prefetch-uite liber; metodele idempotente pot fi reîncercate automat după un timeout de rețea fără riscul de a duplica efecte secundare — de aceea un client poate reîncerca în siguranță un PUT sau DELETE, dar trebuie să fie atent la reîncercarea unui POST (ar putea crea două comenzi). Greșeala clasică este folosirea lui GET pentru a declanșa efecte secundare (ex. GET /users/42/delete), ceea ce strică caching-ul și lasă crawler-ele să mute datele din greșeală. Alegerea metodei potrivite — și respectarea contractului ei de safety și idempotency — este ceea ce face un API previzibil și sigur pentru a construi tooling în jurul lui.
O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează