Kaip HTTP metodai susiejami su CRUD, ir ką reiškia safe bei idempotent?

Question

IT Interview Practice · Accepted Answer

REST naudoja standartinius **HTTP metodus** kaip veiksmažodžius, veikiančius išteklius. Įprastas susiejimas su **CRUD** (Create, Read, Update, Delete) yra:

| CRUD | Method | Tipinis naudojimas |
|------|--------|-------------|
| Create | `POST` | Pridėti naują išteklių į kolekciją |
| Read | `GET` | Paimti išteklių ar sąrašą |
| Update (visas) | `PUT` | Pilnai pakeisti išteklių |
| Update (dalinis) | `PATCH` | Modifikuoti kelis laukus |
| Delete | `DELETE` | Pašalinti išteklių |

## Pavyzdžiai

```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` siunčia **visą** reprezentaciją ir ją pakeičia; `PATCH /users/42` siunčia **tik keistinus laukus** (pvz. `{ "email": "new@example.com" }`).

## Safe vs idempotent

Tai dvi skirtingos savybės:

- **Safe** — metodas **nekeičia** serverio būsenos (tik skaito). `GET`, `HEAD`, `OPTIONS` yra safe.
- **Idempotent** — **tos pačios užklausos** siuntimas N kartų turi tą patį efektą kaip siuntimas vieną kartą. `GET`, `PUT`, `DELETE`, `HEAD` yra idempotent.

```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)
```

## Kodėl tai svarbu

Interviuotojai to klausia, kad pamatytų, ar suprantate HTTP semantiką pakankamai gerai patikimoms API kurti. Safe/idempotent skirtis nėra akademinė: ji tiesiogiai lemia, ką klientams, proxy ir CDN leidžiama daryti. **Safe** metodus galima laisvai cache’inti ir prefetch’inti; **idempotent** metodus galima **automatiškai pakartoti (retry)** po tinklo timeout be rizikos padvigubinti šalutinius efektus — todėl klientas gali saugiai pakartoti `PUT` ar `DELETE`, bet turi būti atsargus kartodamas `POST` (jis gali sukurti du orders). Klasikinė klaida yra `GET` naudojimas šalutiniams efektams sukelti (pvz. `GET /users/42/delete`), kuris sugadina cache’inimą ir leidžia crawleriams netyčia keisti duomenis. Tinkamo metodo pasirinkimas — ir jo safety bei idempotency sutarties gerbimas — yra tai, kas daro API nuspėjamą ir saugų statyti aplink jį įrankius.

Create	`POST`	Pridėti naują išteklių į kolekciją
Read	`GET`	Paimti išteklių ar sąrašą
Update (visas)	`PUT`	Pilnai pakeisti išteklių
Update (dalinis)	`PATCH`	Modifikuoti kelis laukus
Delete	`DELETE`	Pašalinti išteklių

Pavyzdžiai

Safe vs idempotent

Kodėl tai svarbu

Susiję klausimai