HTTP methods CRUD سے کیسے میپ ہوتے ہیں، اور safe اور idempotent کا کیا مطلب ہے؟

Question

IT Interview Practice · Accepted Answer

REST معیاری **HTTP methods** کو ان افعال (verbs) کے طور پر استعمال کرتا ہے جو resources پر عمل کرتے ہیں۔ **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 بمقابلہ idempotent

یہ دو مختلف خصوصیات ہیں:

- **Safe** — method server کی حالت **تبدیل نہیں** کرتا (صرف پڑھنا)۔ `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)
```

## یہ کیوں اہم ہے

انٹرویو لینے والے یہ اس لیے پوچھتے ہیں کہ دیکھ سکیں کہ آپ HTTP کے معانی (semantics) کو قابلِ اعتماد APIs بنانے کے لیے کافی سمجھتے ہیں یا نہیں۔ safe/idempotent کی تمیز محض علمی نہیں ہے: یہ براہِ راست طے کرتی ہے کہ clients، proxies، اور CDNs کو کیا کرنے کی اجازت ہے۔ **Safe** methods کو آزادانہ طور پر cache اور prefetch کیا جا سکتا ہے؛ **idempotent** methods کو کسی نیٹ ورک timeout کے بعد ضمنی اثرات (side effects) کے دہرائے جانے کے خطرے کے بغیر **خودکار طور پر دوبارہ کوشش (retry)** کیا جا سکتا ہے — یہی وجہ ہے کہ کوئی client کسی `PUT` یا `DELETE` کو محفوظ طریقے سے retry کر سکتا ہے مگر `POST` کو retry کرتے وقت محتاط رہنا چاہیے (یہ دو orders بنا سکتا ہے)۔ کلاسک غلطی `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 بمقابلہ idempotent

یہ کیوں اہم ہے

متعلقہ سوالات