Jak metody HTTP mapują się na CRUD i co oznaczają safe oraz idempotent?

Question

IT Interview Practice · Accepted Answer

REST używa standardowych **metod HTTP** jako czasowników działających na zasobach. Popularne mapowanie na **CRUD** (Create, Read, Update, Delete) to:

| CRUD | Metoda | Typowe zastosowanie |
|------|--------|-------------|
| Create | `POST` | Dodanie nowego zasobu do kolekcji |
| Read | `GET` | Pobranie zasobu lub listy |
| Update (pełna) | `PUT` | Całkowite zastąpienie zasobu |
| Update (częściowa) | `PATCH` | Zmiana niektórych pól |
| Delete | `DELETE` | Usunięcie zasobu |

## Przykłady

```http
POST /users HTTP/1.1
Content-Type: application/json

{ "name": "Ann", "email": "ann@example.com" }
```

```http
HTTP/1.1 201 Created
Location: /users/42

{ "id": 42, "name": "Ann", "email": "ann@example.com" }
```

`PUT /users/42` wysyła **całą** reprezentację i ją zastępuje; `PATCH /users/42` wysyła **tylko pola do zmiany** (np. `{ "email": "new@example.com" }`).

## Safe a idempotent

To dwie różne właściwości:

- **Safe (bezpieczna)** — metoda **nie modyfikuje** stanu serwera (tylko do odczytu). `GET`, `HEAD`, `OPTIONS` są safe.
- **Idempotent (idempotentna)** — wykonanie **tego samego żądania N razy** ma ten sam efekt co wykonanie go raz. `GET`, `PUT`, `DELETE`, `HEAD` są idempotentne.

```text
Method   Safe?   Idempotent?
GET      yes     yes
HEAD     yes     yes
PUT      no      yes      (replacing with the same body twice = same result)
DELETE   no      yes      (deleting twice = still deleted)
PATCH    no      no*      (depends on the patch; not guaranteed)
POST     no      no       (posting twice usually creates two resources)
```

## Dlaczego to ważne

Rozmówcy pytają o to, by sprawdzić, czy rozumiesz semantykę HTTP na tyle dobrze, by budować niezawodne API. Rozróżnienie safe/idempotent nie jest akademickie: bezpośrednio rządzi tym, co wolno robić klientom, proxy i CDN-om. Metody **safe** mogą być swobodnie cache'owane i prefetchowane; metody **idempotentne** mogą być **automatycznie ponawiane (retry)** po timeoucie sieci bez ryzyka zduplikowania efektów ubocznych — dlatego klient może bezpiecznie ponowić `PUT` lub `DELETE`, ale musi uważać przy ponawianiu `POST` (może utworzyć dwa zamówienia). Klasyczny błąd to używanie `GET` do wywoływania efektów ubocznych (np. `GET /users/42/delete`), co psuje cache'owanie i pozwala crawlerom przypadkowo zmieniać dane. Wybór właściwej metody — i respektowanie jej kontraktu bezpieczeństwa i idempotentności — to właśnie to, co czyni API przewidywalnym i bezpiecznym do budowania wokół niego narzędzi.

Create	`POST`	Dodanie nowego zasobu do kolekcji
Read	`GET`	Pobranie zasobu lub listy
Update (pełna)	`PUT`	Całkowite zastąpienie zasobu
Update (częściowa)	`PATCH`	Zmiana niektórych pól
Delete	`DELETE`	Usunięcie zasobu

Przykłady

Safe a idempotent

Dlaczego to ważne

Powiązane pytania