HTTP method'ları CRUD'a nasıl eşlenir ve safe ile idempotent ne demektir?

Question

IT Interview Practice · Accepted Answer

REST, resource'lar üzerinde eylemde bulunan fiiller olarak standart **HTTP method'larını** kullanır. **CRUD** (Create, Read, Update, Delete) ile yaygın eşleme şöyledir:

| CRUD | Method | Tipik kullanım |
|------|--------|-------------|
| Create | `POST` | Bir collection'a yeni resource ekler |
| Read | `GET` | Bir resource veya liste getirir |
| Update (tam) | `PUT` | Resource'u tamamen değiştirir |
| Update (kısmi) | `PATCH` | Bazı alanları değiştirir |
| Delete | `DELETE` | Resource'u kaldırır |

## Örnekler

```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`, **tüm** representation'ı gönderir ve onu değiştirir; `PATCH /users/42` ise **yalnızca değişecek alanları** gönderir (ör. `{ "email": "new@example.com" }`).

## Safe vs idempotent

Bunlar iki farklı özelliktir:

- **Safe** — method server durumunu **değiştirmez** (salt okunur). `GET`, `HEAD`, `OPTIONS` safe'tir.
- **Idempotent** — **aynı isteği N kez** yapmak, bir kez yapmakla aynı etkiye sahiptir. `GET`, `PUT`, `DELETE`, `HEAD` idempotent'tir.

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

## Neden önemli

Mülakatçılar bunu, güvenilir API'ler kurmaya yetecek kadar HTTP semantiğini anlayıp anlamadığınızı görmek için sorar. Safe/idempotent ayrımı akademik değildir: client'ların, proxy'lerin ve CDN'lerin ne yapmasına izin verildiğini doğrudan belirler. **Safe** method'lar serbestçe cache'lenip prefetch edilebilir; **idempotent** method'lar bir ağ timeout'undan sonra yan etkileri (side effect) çoğaltma riski olmadan **otomatik olarak yeniden denenebilir** — bu yüzden bir client bir `PUT` ya da `DELETE`'i güvenle yeniden deneyebilir ama bir `POST`'u yeniden denerken dikkatli olmalıdır (iki order oluşturabilir). Klasik hata, yan etki tetiklemek için `GET` kullanmaktır (ör. `GET /users/42/delete`); bu, cache'lemeyi bozar ve crawler'ların yanlışlıkla veriyi değiştirmesine izin verir. Doğru method'u seçmek — ve onun safety ve idempotency sözleşmesine saygı göstermek — bir API'yi öngörülebilir ve etrafına araç (tooling) kurmaya güvenli kılan şeydir.

Create	`POST`	Bir collection'a yeni resource ekler
Read	`GET`	Bir resource veya liste getirir
Update (tam)	`PUT`	Resource'u tamamen değiştirir
Update (kısmi)	`PATCH`	Bazı alanları değiştirir
Delete	`DELETE`	Resource'u kaldırır

Örnekler

Safe vs idempotent

Neden önemli

İlgili sorular