HTTP methods CRUD-க்கு எப்படி map ஆகின்றன, மேலும் safe மற்றும் idempotent என்றால் என்ன?

Question

IT Interview Practice · Accepted Answer

REST resources மீது செயல்படும் verbs ஆக standard **HTTP methods**-ஐப் பயன்படுத்துகிறது. **CRUD** (Create, Read, Update, Delete)-க்கான பொதுவான mapping:

| CRUD | Method | பொதுவான பயன்பாடு |
|------|--------|-------------|
| Create | `POST` | ஒரு collection-க்கு புதிய resource சேர்த்தல் |
| Read | `GET` | ஒரு resource அல்லது list-ஐப் பெறுதல் |
| Update (முழு) | `PUT` | ஒரு resource-ஐ முழுமையாக மாற்றுதல் |
| Update (பகுதி) | `PATCH` | சில fields-ஐ மாற்றுதல் |
| Delete | `DELETE` | ஒரு resource-ஐ அகற்றுதல் |

## எடுத்துக்காட்டுகள்

```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` **முழு** representation-ஐ அனுப்பி அதை மாற்றுகிறது; `PATCH /users/42` **மாற்ற வேண்டிய fields-ஐ மட்டும்** அனுப்புகிறது (உ.ம். `{ "email": "new@example.com" }`).

## Safe vs idempotent

இவை இரண்டு வெவ்வேறு பண்புகள்:

- **Safe** — method server state-ஐ **மாற்றாது** (read-only). `GET`, `HEAD`, `OPTIONS` safe.
- **Idempotent** — **அதே request-ஐ N முறை** செய்வது ஒரு முறை செய்வதன் அதே விளைவைக் கொண்டுள்ளது. `GET`, `PUT`, `DELETE`, `HEAD` 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)
```

## இது ஏன் முக்கியம்

நம்பகமான APIs-ஐ உருவாக்கும் அளவுக்கு HTTP semantics-ஐ நீங்கள் புரிந்துகொள்கிறீர்களா என்று பார்க்க interviewers இதைக் கேட்கிறார்கள். Safe/idempotent வேறுபாடு கல்விசார்ந்ததல்ல: clients, proxies, மற்றும் CDNs என்ன செய்ய அனுமதிக்கப்படுகின்றன என்பதை இது நேரடியாக நிர்வகிக்கிறது. **Safe** methods சுதந்திரமாக cache மற்றும் prefetch செய்யப்படலாம்; **idempotent** methods ஒரு network timeout-க்குப் பிறகு side effects-ஐ நகலெடுக்கும் அபாயமின்றி **தானாக retry** செய்யப்படலாம் — அதனால்தான் ஒரு client ஒரு `PUT` அல்லது `DELETE`-ஐ பாதுகாப்பாக retry செய்யலாம் ஆனால் ஒரு `POST`-ஐ retry செய்வதில் கவனமாக இருக்க வேண்டும் (அது இரண்டு orders-ஐ உருவாக்கலாம்). உன்னதமான தவறு side effects-ஐத் தூண்ட `GET`-ஐப் பயன்படுத்துவது (உ.ம். `GET /users/42/delete`), இது caching-ஐ உடைத்து crawlers தற்செயலாக data-ஐ மாற்ற அனுமதிக்கிறது. சரியான method-ஐத் தேர்ந்தெடுப்பது — மற்றும் அதன் safety மற்றும் idempotency contract-ஐ மதிப்பது — ஒரு API-ஐ கணிக்கக்கூடியதாகவும் அதைச் சுற்றி tooling கட்ட பாதுகாப்பாகவும் ஆக்குகிறது.

Create	`POST`	ஒரு collection-க்கு புதிய resource சேர்த்தல்
Read	`GET`	ஒரு resource அல்லது list-ஐப் பெறுதல்
Update (முழு)	`PUT`	ஒரு resource-ஐ முழுமையாக மாற்றுதல்
Update (பகுதி)	`PATCH`	சில fields-ஐ மாற்றுதல்
Delete	`DELETE`	ஒரு resource-ஐ அகற்றுதல்

எடுத்துக்காட்டுகள்

Safe vs idempotent

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்