Hoe mappen HTTP-methoden op CRUD, en wat betekenen safe en idempotent?

Question

IT Interview Practice · Accepted Answer

REST gebruikt standaard **HTTP-methoden** als de werkwoorden die op resources inwerken. De gangbare mapping naar **CRUD** (Create, Read, Update, Delete) is:

| CRUD | Method | Typisch gebruik |
|------|--------|-------------|
| Create | `POST` | Voeg een nieuwe resource toe aan een collectie |
| Read | `GET` | Haal een resource of lijst op |
| Update (volledig) | `PUT` | Vervang een resource volledig |
| Update (gedeeltelijk) | `PATCH` | Wijzig sommige velden |
| Delete | `DELETE` | Verwijder een resource |

## Voorbeelden

```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` stuurt de **hele** representatie en vervangt hem; `PATCH /users/42` stuurt **alleen de te wijzigen velden** (bv. `{ "email": "new@example.com" }`).

## Safe versus idempotent

Dit zijn twee verschillende eigenschappen:

- **Safe** — de methode **wijzigt** de serverstate **niet** (alleen-lezen). `GET`, `HEAD`, `OPTIONS` zijn safe.
- **Idempotent** — **dezelfde request N keer** doen heeft hetzelfde effect als hem één keer doen. `GET`, `PUT`, `DELETE`, `HEAD` zijn 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)
```

## Waarom het belangrijk is

Interviewers vragen dit om te zien of je de HTTP-semantiek goed genoeg begrijpt om betrouwbare API's te bouwen. Het onderscheid safe/idempotent is niet academisch: het bepaalt rechtstreeks wat clients, proxy's en CDN's mogen doen. **Safe**-methoden mogen vrij gecachet en geprefetcht worden; **idempotente** methoden mogen na een netwerk-timeout **automatisch opnieuw geprobeerd** worden zonder risico op het dupliceren van side effects — en daarom kan een client veilig een `PUT` of `DELETE` opnieuw proberen maar moet hij voorzichtig zijn met het opnieuw proberen van een `POST` (het zou twee orders kunnen aanmaken). De klassieke fout is `GET` gebruiken om side effects te triggeren (bv. `GET /users/42/delete`), wat caching breekt en crawlers per ongeluk data laat muteren. De juiste methode kiezen — en zijn safety- en idempotency-contract respecteren — is wat een API voorspelbaar en veilig maakt om tooling omheen te bouwen.

Create	`POST`	Voeg een nieuwe resource toe aan een collectie
Read	`GET`	Haal een resource of lijst op
Update (volledig)	`PUT`	Vervang een resource volledig
Update (gedeeltelijk)	`PATCH`	Wijzig sommige velden
Delete	`DELETE`	Verwijder een resource

Voorbeelden

Safe versus idempotent

Waarom het belangrijk is

Gerelateerde vragen