Bagaimana HTTP method dipetakan ke CRUD, dan apa arti safe dan idempotent?

Question

IT Interview Practice · Accepted Answer

REST menggunakan **HTTP method** standar sebagai kata kerja yang beraksi pada resource. Pemetaan umum ke **CRUD** (Create, Read, Update, Delete) adalah:

| CRUD | Method | Penggunaan tipikal |
|------|--------|-------------|
| Create | `POST` | Menambahkan resource baru ke sebuah collection |
| Read | `GET` | Mengambil sebuah resource atau daftar |
| Update (penuh) | `PUT` | Mengganti sebuah resource sepenuhnya |
| Update (parsial) | `PATCH` | Memodifikasi sebagian field |
| Delete | `DELETE` | Menghapus sebuah resource |

## Contoh

```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` mengirim representasi **utuh** dan menggantinya; `PATCH /users/42` mengirim **hanya field yang akan diubah** (mis. `{ "email": "new@example.com" }`).

## Safe vs idempotent

Ini adalah dua properti yang berbeda:

- **Safe** — method **tidak memodifikasi** state server (read-only). `GET`, `HEAD`, `OPTIONS` adalah safe.
- **Idempotent** — membuat **request yang sama N kali** memiliki efek yang sama dengan membuatnya sekali. `GET`, `PUT`, `DELETE`, `HEAD` adalah 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)
```

## Mengapa ini penting

Pewawancara menanyakan ini untuk melihat apakah Anda memahami semantik HTTP cukup baik untuk membangun API yang andal. Pembedaan safe/idempotent bukan hal akademis: ia secara langsung mengatur apa yang boleh dilakukan client, proxy, dan CDN. Method **safe** bisa di-cache dan di-prefetch dengan bebas; method **idempotent** bisa **di-retry secara otomatis** setelah timeout jaringan tanpa risiko menduplikasi side effect — itulah mengapa client bisa dengan aman me-retry sebuah `PUT` atau `DELETE` tetapi harus hati-hati me-retry sebuah `POST` (ia mungkin membuat dua order). Kesalahan klasiknya adalah menggunakan `GET` untuk memicu side effect (mis. `GET /users/42/delete`), yang merusak caching dan membiarkan crawler tanpa sengaja memutasi data. Memilih method yang tepat — dan menghormati kontrak safety dan idempotency-nya — adalah yang membuat sebuah API dapat diprediksi dan aman untuk dibangun tooling di sekitarnya.

Create	`POST`	Menambahkan resource baru ke sebuah collection
Read	`GET`	Mengambil sebuah resource atau daftar
Update (penuh)	`PUT`	Mengganti sebuah resource sepenuhnya
Update (parsial)	`PATCH`	Memodifikasi sebagian field
Delete	`DELETE`	Menghapus sebuah resource

Contoh

Safe vs idempotent

Mengapa ini penting

Pertanyaan terkait