Kako se metode HTTP preslikajo na CRUD in kaj pomenita safe ter idempotent?

Question

IT Interview Practice · Accepted Answer

REST uporablja standardne **metode HTTP** kot glagole, ki delujejo na virih. Pogosta preslikava na **CRUD** (Create, Read, Update, Delete) je:

| CRUD | Metoda | Tipična raba |
|------|--------|-------------|
| Create | `POST` | Dodaj nov vir v zbirko |
| Read | `GET` | Pridobi vir ali seznam |
| Update (poln) | `PUT` | V celoti zamenjaj vir |
| Update (delen) | `PATCH` | Spremeni nekaj polj |
| Delete | `DELETE` | Odstrani vir |

## Primeri

```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` pošlje **celotno** predstavitev in jo zamenja; `PATCH /users/42` pošlje **samo polja, ki jih je treba spremeniti** (npr. `{ "email": "new@example.com" }`).

## Safe proti idempotent

To sta dve različni lastnosti:

- **Safe** — metoda **ne spremeni** stanja strežnika (samo branje). `GET`, `HEAD`, `OPTIONS` so safe.
- **Idempotent** — **ista zahteva N-krat** ima enak učinek kot enkrat. `GET`, `PUT`, `DELETE`, `HEAD` so 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)
```

## Zakaj je to pomembno

Spraševalci to sprašujejo, da vidijo, ali dovolj dobro razumete semantiko HTTP, da zgradite zanesljive API-je. Razlika safe/idempotent ni akademska: neposredno določa, kaj smejo početi odjemalci, proxyji in CDN-ji. **Safe** metode je mogoče prosto predpomniti in vnaprej naložiti; **idempotentne** metode je mogoče po omrežni prekinitvi **samodejno ponoviti (retry)** brez tveganja podvajanja stranskih učinkov — zato lahko odjemalec varno ponovi `PUT` ali `DELETE`, previden pa mora biti pri ponovitvi `POST` (lahko ustvari dve naročili). Klasična napaka je uporaba `GET` za sprožitev stranskih učinkov (npr. `GET /users/42/delete`), kar pokvari predpomnjenje in omogoči, da pajki (crawlers) nehote spremenijo podatke. Izbira prave metode — in spoštovanje njene pogodbe o varnosti in idempotentnosti — je tisto, kar naredi API predvidljiv in varen za gradnjo orodij okoli njega.

Create	`POST`	Dodaj nov vir v zbirko
Read	`GET`	Pridobi vir ali seznam
Update (poln)	`PUT`	V celoti zamenjaj vir
Update (delen)	`PATCH`	Spremeni nekaj polj
Delete	`DELETE`	Odstrani vir

Primeri

Safe proti idempotent

Zakaj je to pomembno

Povezana vprašanja