HTTP methodలు CRUDకు ఎలా మ్యాప్ అవుతాయి, safe మరియు idempotent అంటే ఏమిటి?

Question

IT Interview Practice · Accepted Answer

REST resources మీద పనిచేసే verbsగా standard **HTTP methods**ను వాడుతుంది. **CRUD** (Create, Read, Update, Delete)కు సాధారణ మ్యాపింగ్:

| CRUD | Method | సాధారణ వాడకం |
|------|--------|-------------|
| Create | `POST` | ఒక collectionకు కొత్త resourceను జోడించడం |
| Read | `GET` | ఒక resource లేదా జాబితాను పొందడం |
| 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)
```

## ఇది ఎందుకు ముఖ్యం

మీరు నమ్మదగిన APIలను నిర్మించడానికి HTTP semanticsను తగినంతగా అర్థం చేసుకున్నారో లేదో చూడటానికి ఇంటర్వ్యూయర్‌లు దీన్ని అడుగుతారు. safe/idempotent తేడా అకడమిక్ కాదు: ఇది clients, proxies, CDNలు ఏమి చేయడానికి అనుమతించబడతాయో నేరుగా నిర్ణయిస్తుంది. **Safe** methodలను స్వేచ్ఛగా cache, prefetch చేయవచ్చు; **idempotent** methodలను ఒక network timeout తర్వాత side effectలను నకిలీ చేసే ప్రమాదం లేకుండా **స్వయంచాలకంగా retry** చేయవచ్చు — అందుకే ఒక client `PUT` లేదా `DELETE`ను సురక్షితంగా retry చేయగలదు కానీ `POST`ను retry చేయడంలో జాగ్రత్తగా ఉండాలి (అది రెండు orders సృష్టించవచ్చు). క్లాసిక్ తప్పు side effectలను ప్రేరేపించడానికి `GET`ను వాడటం (ఉదా. `GET /users/42/delete`), ఇది cachingను విచ్ఛిన్నం చేస్తుంది, crawlers అనుకోకుండా డేటాను మార్చనిస్తుంది. సరైన methodను ఎంచుకోవడం — దాని safety మరియు idempotency ఒప్పందాన్ని గౌరవించడం — ఒక APIని ఊహించదగినదిగా, దాని చుట్టూ tooling నిర్మించడానికి సురక్షితంగా చేస్తుంది.

Create	`POST`	ఒక collectionకు కొత్త resourceను జోడించడం
Read	`GET`	ఒక resource లేదా జాబితాను పొందడం
Update (పూర్తి)	`PUT`	ఒక resourceను పూర్తిగా భర్తీ చేయడం
Update (పాక్షిక)	`PATCH`	కొన్ని fieldsను మార్చడం
Delete	`DELETE`	ఒక resourceను తొలగించడం

ఉదాహరణలు

Safe vs idempotent

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు