REST ले resource हरूमा कार्य गर्ने verb का रूपमा standard HTTP method हरू प्रयोग गर्छ। CRUD (Create, Read, Update, Delete) मा सामान्य mapping यस्तो छ:
REST ले resource हरूमा कार्य गर्ने verb का रूपमा standard HTTP method हरू प्रयोग गर्छ। CRUD (Create, Read, Update, Delete) मा सामान्य mapping यस्तो छ:
| CRUD | Method | सामान्य प्रयोग |
|---|
| Create | POST | एउटा collection मा नयाँ resource थप्ने |
| Read | GET | एउटा resource वा list ल्याउने |
| Update (पूर्ण) | PUT | resource लाई पूर्ण रूपमा replace गर्ने |
| Update (आंशिक) | PATCH | केही field हरू परिवर्तन गर्ने |
| Delete | DELETE | एउटा resource हटाउने |
POST /users HTTP/1.1
Content-Type: application/json
{ "name": "Ann", "email": "[email protected]" }
HTTP/1.1 201 Created
Location: /users/42
{ "id": 42, "name": "Ann", "email": "[email protected]" }
PUT /users/42 ले पूरै representation पठाउँछ र त्यसलाई replace गर्छ; PATCH /users/42 ले परिवर्तन गर्नुपर्ने field हरू मात्र पठाउँछ (जस्तै { "email": "[email protected]" })।
यी दुई फरक गुण हुन्:
GET, HEAD, OPTIONS safe हुन्।GET, PUT, DELETE, HEAD idempotent हुन्।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)
Interviewer हरूले यो तपाईंले भरपर्दो API बनाउन HTTP semantics पर्याप्त बुझ्नुहुन्छ कि भनेर हेर्न सोध्छन्। Safe/idempotent भिन्नता शैक्षिक होइन: यसले client, proxy, र CDN हरूले के गर्न पाउँछन् भन्ने कुरालाई सीधै निर्देशित गर्छ। Safe method हरू स्वतन्त्र रूपमा cache र prefetch गर्न सकिन्छ; idempotent method हरू network timeout पछि side effect दोहोर्याउने जोखिम बिना स्वचालित रूपमा retry गर्न सकिन्छ — यही कारण client ले PUT वा DELETE सुरक्षित रूपमा retry गर्न सक्छ तर POST retry गर्दा सावधान हुनुपर्छ (यसले दुई order बनाउन सक्छ)। उत्कृष्ट गल्ती भनेको side effect trigger गर्न GET प्रयोग गर्नु हो (जस्तै GET /users/42/delete), जसले caching बिगार्छ र crawler हरूलाई गल्तीले data परिवर्तन गर्न दिन्छ। सही method छान्नु — र यसको safety र idempotency सम्झौताको सम्मान गर्नु — नै एउटा API लाई अनुमानयोग्य र त्यसको वरिपरि tooling बनाउन सुरक्षित बनाउने कुरा हो।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्