REST API इंटरव्यू प्रश्न और उत्तर (2026 गाइड)

REST APIs इंटरनेट की ज्यादातर इंटीग्रेशंस को शक्ति देती हैं। चाहे आप बैकएंड रोल, फुल-स्टैक पोज़ीशन, या सॉफ्टवेयर इंजीनियरिंग जॉब के लिए अप्लाई कर रहे हों, आपसे REST API डिजाइन, HTTP methods, और authentication पैटर्न्स पर सवाल ज़रूर पूछे जाएंगे।

इस गाइड में, मैं आपको वही सवाल समझाऊंगा जो इंटरव्यूअर वास्तव में पूछते हैं। मैंने इन्हें कठिनाई स्तर और रोल-टाइप के आधार पर व्यवस्थित किया है ताकि आप अपने लक्ष्य पद के लिए सबसे ज़रूरी चीज़ों पर फोकस कर सकें। हर उत्तर में व्यावहारिक उदाहरण और जहाँ ज़रूरी हो, ऐसे कोड स्निपेट शामिल हैं जिन्हें आप अपना सकते हैं।

एक बात ध्यान में रखें: इंटरव्यूअर उन्नत विषयों की तुलना में बुनियादी सिद्धांतों का कहीं ज़्यादा परीक्षण करते हैं। अगर आप बेसिक्स (HTTP methods, status codes, statelessness) में निपुण हैं, तो अधिकतर REST API इंटरव्यू आप आत्मविश्वास से संभाल लेंगे। जटिल आर्किटेक्चरल पैटर्न बाद में आते हैं।

बेसिक REST API इंटरव्यू प्रश्न

ये प्रश्न आपकी नींव की समझ को परखते हैं। इन्हें लगभग हर इंटरव्यू में, सिनियॉरिटी स्तर की परवाह किए बिना, अपेक्षित मानें।

1. REST क्या है और इसकी बाध्यताएँ (constraints) क्या हैं?

REST का अर्थ है Representational State Transfer। यह नेटवर्क्ड एप्लिकेशंस को डिज़ाइन करने की एक आर्किटेक्चरल शैली है, जिसे Roy Fielding ने 2000 की अपनी डॉक्टोरल थीसिस में परिभाषित किया था।

REST में छह constraints होती हैं:

1. Client-Server: यूज़र इंटरफ़ेस और डेटा स्टोरेज के बीच दायित्वों का पृथक्करण
2. Stateless: हर रिक्वेस्ट में उसे पूरा करने के लिए आवश्यक सभी जानकारी होनी चाहिए
3. Cacheable: रेस्पॉन्स यह बताएं कि वे कैश किए जा सकते हैं या नहीं
4. Layered System: कंपोनेंट्स अपनी तात्कालिक लेयर से आगे नहीं देख सकें
5. Uniform Interface: रिसोर्स के साथ इंटरैक्ट करने का मानकीकृत तरीका
6. Code-on-Demand (वैकल्पिक): सर्वर क्लाइंट्स को executable कोड भेज सकते हैं

2. REST और SOAP में क्या अंतर है?

REST एक आर्किटेक्चरल शैली है; SOAP एक प्रोटोकॉल। REST आमतौर पर HTTP पर JSON का उपयोग करता है और मानक HTTP methods का लाभ उठाता है। SOAP विशेष रूप से XML का उपयोग करता है और अपने लिफ़ाफ़ों और हेडर्स के साथ अपना मैसेजिंग फॉर्मेट परिभाषित करता है।

एंटरप्राइज़ सिस्टम्स जिनमें औपचारिक कॉन्ट्रैक्ट्स (WSDL) या मैसेज-लेवल सिक्योरिटी (WS-Security) की ज़रूरत होती है, उनके लिए SOAP अब भी समझदारी हो सकती है।

3. HTTP methods क्या हैं और किसे कब उपयोग करें?

HTTP methods किसी रिसोर्स पर की जाने वाली क्रिया को परिभाषित करते हैं।

4. PUT और POST में क्या अंतर है?

POST एक नया रिसोर्स बनाता है जहाँ सर्वर URI तय करता है। PUT क्लाइंट द्वारा दिए गए विशिष्ट URI पर रिसोर्स को बदल देता है।

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resourceसंचालित द्वारा

यदि आप किसी ऐसे URI पर PUT करें जो मौजूद नहीं है, तो सर्वर उसे बना सकता है। यदि आप मौजूदा URI पर PUT करें, तो आप पूरे रिसोर्स को बदल देते हैं।

5. PUT और PATCH में क्या अंतर है?

PUT पूरे रिसोर्स को बदलता है। PATCH आंशिक बदलाव लागू करता है।

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "[email protected]", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}संचालित द्वारा

6. REST में "stateless" का क्या अर्थ है?

Stateless का अर्थ है कि हर रिक्वेस्ट में वह सारी जानकारी होनी चाहिए जिसकी सर्वर को उसे प्रोसेस करने के लिए ज़रूरत है। सर्वर रिक्वेस्ट्स के बीच कोई क्लाइंट कॉन्टेक्स्ट स्टोर नहीं करता।

इसका मतलब है सर्वर-साइड सेशन्स नहीं। यदि कोई यूज़र प्रमाणीकृत है, तो क्लाइंट को हर रिक्वेस्ट के साथ प्रमाण-पत्र (आमतौर पर एक टोकन) भेजना होगा।

7. किसी API को RESTful क्या बनाता है?

API तभी सचमुच RESTful होता है जब वह सभी REST constraints को पूरा करता है, जिनमें HATEOAS (Hypermedia as the Engine of Application State) शामिल है। व्यवहार में, ज्यादातर API जो खुद को "REST" कहते हैं, वास्तव में "REST-like" या Richardson Maturity Model के Level 2 पर होते हैं। और सच कहें, तो अधिकतर उपयोग मामलों के लिए यह पर्याप्त होता है।

REST APIs के लिए Richardson Maturity Model के स्तर। छवि: लेखक।

8. वे बुनियादी HTTP status codes कौन-से हैं जिन्हें आपको पता होना चाहिए?

आपको कम-से-कम ये सात आवश्यक status codes पता होने चाहिए, जो अधिकतर API परिदृश्यों को कवर करते हैं:

9. रिसोर्स और एंडपॉइंट में क्या अंतर है?

रिसोर्स डेटा एंटिटी है (यूज़र, ऑर्डर, प्रोडक्ट)। एंडपॉइंट वह URL पाथ है जो उस रिसोर्स तक पहुँच देता है।

Resource: User
Endpoints: GET /users, GET /users/123, POST /usersसंचालित द्वारा

10. URI डिजाइन के लिए सर्वोत्तम प्रथाएँ क्या हैं?

क्रियाओं (verbs) नहीं, संज्ञाओं (nouns) का उपयोग करें। URI लोअरकेस रखें और बहु-शब्द नामों के लिए हाइफ़न का उपयोग करें। कलेक्शंस के लिए बहुवचन संज्ञाएँ रखें।

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_itemsसंचालित द्वारा

गहरी nesting से बचें। /users/123/posts/456/comments/789 की बजाय /comments/789 या /comments?post_id=456 पर विचार करें।

11. Idempotency क्या है और कौन-से HTTP methods idempotent हैं?

यदि किसी ऑपरेशन को कई बार करने पर वही परिणाम मिले जो एक बार करने पर मिलता है, तो वह idempotent है।

जो PATCH किसी मान को सेट करता है, वह idempotent है; जो PATCH काउंटर को इन्क्रिमेंट करता है, वह नहीं।

12. Safe और idempotent methods में क्या अंतर है?

Safe methods रिसोर्स को मॉडिफाई नहीं करते (GET, HEAD, OPTIONS)। Idempotent methods को कई बार कॉल करने पर समान प्रभाव रहता है (GET, PUT, DELETE)।

सभी safe methods idempotent हैं, पर सभी idempotent methods safe नहीं हैं। DELETE idempotent है पर safe नहीं, क्योंकि यह स्टेट बदलता है।

13. Query parameters और path parameters कब उपयोग करने चाहिए?

Path parameters किसी विशिष्ट रिसोर्स की पहचान करते हैं। Query parameters कलेक्शंस को फ़िल्टर, सॉर्ट या paginate करते हैं।

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10संचालित द्वारा

14. Content negotiation क्या है?

Content negotiation क्लाइंट्स को किसी रिसोर्स के अलग-अलग प्रतिनिधित्व माँगने देता है। क्लाइंट Accept हेडर भेजता है, और सर्वर उपयुक्त फॉर्मेट में जवाब देता है।

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XMLसंचालित द्वारा

15. OPTIONS method का उद्देश्य क्या है?

OPTIONS किसी विशिष्ट URL के लिए सर्वर किन HTTP methods को सपोर्ट करता है, यह लौटाता है। ब्राउज़र CORS preflight के लिए इसका उपयोग करते हैं ताकि यह जाँचा जा सके कि cross-origin रिक्वेस्ट्स की अनुमति है या नहीं।

इंटरमीडिएट REST API इंटरव्यू प्रश्न

ये प्रश्न व्यावहारिक उपयोग और निर्णय-क्षमता को परखते हैं। मिड-लेवल पदों के लिए इन्हें अपेक्षित मानें।

16. 401 और 403 में क्या अंतर है?

यह status codes की सबसे आम उलझन है। मैंने सीनियर इंजीनियर्स को भी कोड रिव्यू में इन्हें मिलाते देखा है।

401 Unauthorized

मतलब unauthenticated। सर्वर नहीं जानता कि आप कौन हैं। आपका रेस्पॉन्स यूज़र को लॉगिन के लिए प्रेरित करना चाहिए।

403 Forbidden

मतलब unauthorized। सर्वर जानता है कि आप कौन हैं, पर आपके पास अनुमति नहीं है। दोबारा authenticate करने से मदद नहीं मिलेगी।

प्रमाणीकरण बनाम अधिकृत-प्रवेश (authorization) त्रुटि निर्णय फ़्लोचार्ट। छवि: लेखक।

17. 400 और 422 में क्या अंतर है?

अंतर को दर्शाने के लिए उदाहरण:

400 Bad Request

यह गलत सिंटैक्स को दर्शाता है। सर्वर रिक्वेस्ट को पार्स नहीं कर सकता (अमान्य JSON संरचना, आवश्यक हेडर्स गायब)।

422 Unprocessable Entity

यह वैध सिंटैक्स लेकिन अर्थगत त्रुटियों को दर्शाता है। JSON वैध है पर डेटा वैलिडेशन में फेल (अमान्य ईमेल फॉर्मेट, बहुत छोटा पासवर्ड)।

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validationसंचालित द्वारा

18. 409 Conflict कब उपयोग करना चाहिए?

409 का उपयोग तब करें जब रिक्वेस्ट रिसोर्स की वर्तमान स्थिति से टकराती हो:

• Optimistic locking विफलताएँ (ETag mismatch)
• यूनिक constraint उल्लंघन (डुप्लिकेट यूज़रनेम)
• अमान्य स्टेट ट्रांज़िशन (पहले ही शिप हुए ऑर्डर को कैंसल करना)

19. आप pagination कैसे लागू करते हैं?

दो मुख्य तरीके:

Offset-आधारित pagination

सरल, पर बड़े डेटा सेट्स के साथ परफॉर्मेंस समस्याएँ।

GET /users?limit=20&offset=40संचालित द्वारा

Cursor-आधारित pagination

बेहतर स्केल करता है और डेटा बदलने पर "page drift" से बचाता है।

GET /users?limit=20&cursor=eyJpZCI6MTIzfQसंचालित द्वारा

Stripe, GitHub, और Slack जैसी कंपनियाँ बड़े डेटा सेट्स के लिए cursor-आधारित pagination का उपयोग करती हैं।

20. आम API versioning स्ट्रैटेजीज़ क्या हैं?

तीन मुख्य तरीके हैं, जिनके अलग-अलग trade-offs हैं:

URI वर्ज़निंग

सबसे आम। स्पष्ट और डिबग करने में आसान।

GET /v1/users
GET /v2/usersसंचालित द्वारा

हेडर वर्ज़निंग

URLs साफ़ रहते हैं, पर ब्राउज़र्स में टेस्ट करना कठिन।

GET /users
Accept-Version: v2संचालित द्वारा

क्वेरी पैरामीटर वर्ज़निंग

जोड़ना आसान, पर URLs को अव्यवस्थित करता है।

GET /users?version=2संचालित द्वारा

21. ETag क्या है और कैशिंग कैसे काम करती है?

ETag किसी रिसोर्स के लिए एक वर्ज़न पहचानकर्ता है। सर्वर इसे रेस्पॉन्स में भेजता है; क्लाइंट बाद की रिक्वेस्ट्स में वापस भेजता है ताकि पता चल सके कि रिसोर्स बदला है या नहीं।

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)संचालित द्वारा

22. REST APIs के लिए कौन-सी authentication विधियाँ उपयोग होती हैं?

चार सबसे आम विधियाँ हैं: API Keys, Bearer Tokens, OAuth 2.0, और JWT:

23. JWT क्या है और यह कैसे काम करता है?

JWT (JSON Web Token) तीन भागों से बना होता है: Header, Payload, और Signature। Python में JSON के साथ काम करना और जानें।

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)संचालित द्वारा

सर्वर टोकन पर हस्ताक्षर करता है; क्लाइंट्स इसे रिक्वेस्ट्स के साथ भेजते हैं। सर्वर बिना डेटाबेस लुकअप के सिग्नेचर को वैलिडेट करता है।

24. RS256 और HS256 में क्या अंतर है?

HS256 (सिमेट्रिक): वही सीक्रेट साइन और वेरिफाई करता है। जोखिम तब बढ़ता है जब कई सेवाओं को टोकन वेरिफाई करने हों।

RS256 (असिमेट्रिक): प्राइवेट की साइन करती है, पब्लिक की वेरिफाई करती है। वितरित सिस्टम्स के लिए अनुशंसित जहाँ कई सेवाएँ टोकन वैलिडेट करती हैं।

25. HATEOAS क्या है?

HATEOAS (Hypermedia as the Engine of Application State) का मतलब है कि रेस्पॉन्स में संबंधित क्रियाओं और रिसोर्सेज़ के लिंक शामिल हों।

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}संचालित द्वारा

व्यवहार में, अधिकतर APIs HATEOAS को पूरी तरह लागू नहीं करतीं। अवधारणा जानें, पर अधिकांश नौकरियों में इसे पूर्ण रूप से लागू करने की अपेक्षा न रखें। बड़ी टेक कंपनियाँ भी शायद ही कभी पूरी तरह HATEOAS-अनुपालक APIs बनाती हैं।

26. आप त्रुटियों (errors) को लगातार तरीके से कैसे संभालते हैं?

सुसंगत error रेस्पॉन्सेस के लिए RFC 7807 Problem Details फॉर्मेट का उपयोग करें:

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}संचालित द्वारा

27. Rate limiting क्या है और यह महत्वपूर्ण क्यों है?

Rate limiting आपके API को दुरुपयोग से बचाता है और निष्पक्ष उपयोग सुनिश्चित करता है। सामान्य रेस्पॉन्स:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0संचालित द्वारा

28. आप फ़िल्टरिंग और सॉर्टिंग कैसे डिज़ाइन करते हैं?

स्पष्ट कन्वेंशन्स के साथ query parameters का उपयोग करें:

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,nameसंचालित द्वारा

एडवांस्ड REST API इंटरव्यू प्रश्न

ये प्रश्न आर्किटेक्चरल सोच को परखते हैं। सीनियर पदों के लिए अपेक्षित मानें।

29. OAuth 2.0 और OAuth 2.1 में क्या बदला?

OAuth 2.1 सुरक्षा से जुड़ी श्रेष्ठ प्रथाओं को समेकित करता है:

मुख्य निष्कर्ष: सभी क्लाइंट प्रकारों के लिए Authorization Code flow के साथ PKCE का उपयोग करें।

30. पेमेंट एंडपॉइंट्स के लिए idempotency कैसे लागू करेंगे?

POST रिक्वेस्ट्स को रिट्राइज़ के लिए सुरक्षित बनाने हेतु idempotency keys का उपयोग करें:

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return resultसंचालित द्वारा

क्लाइंट एक UUID जनरेट करता है और रिक्वेस्ट के साथ भेजता है। यदि वही key दोबारा आए, तो cached रेस्पॉन्स लौटा दें।

31. आप एक वितरित rate limiter कैसे डिज़ाइन करेंगे?

डिस्ट्रिब्यूटेड सिस्टम्स के लिए आप इन-मैमोरी काउंटर्स का उपयोग नहीं कर सकते क्योंकि ट्रैफिक लोड-बैलेंस होकर कई इंस्टेंसेज़ में बँटा होता है। यह एक आम गलती है जो उम्मीदवारों को उलझा देती है।

आर्किटेक्चर:

1. केंद्रीकृत काउंटर स्टोरेज के लिए Redis का उपयोग करें
2. बर्स्ट सहनशीलता हेतु Token Bucket एल्गोरिद्म लागू करें
3. रेस कंडीशन्स से बचने के लिए एटॉमिक ऑपरेशन्स (Lua स्क्रिप्ट्स) उपयोग करें

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429संचालित द्वारा

32. आप gRPC को REST पर कब चुनेंगे?

gRPC चुनें जब:

• आंतरिक माइक्रोसर्विस कम्युनिकेशन (5-10x थ्रूपुट सुधार)
• रीयल-टाइम स्ट्रीमिंग आवश्यकताएँ
• मोबाइल-टू-बैकएंड बैंडविड्थ सीमाएँ
• कड़े कॉन्ट्रैक्ट्स वाली polyglot एनवायरनमेंट्स

REST चुनें जब:

• विविध उपभोक्ताओं वाले पब्लिक APIs
• वेब एप्लिकेशंस (सार्वभौमिक ब्राउज़र सपोर्ट)
• सरल CRUD ऑपरेशन्स
• टीमें Protocol Buffers से अपरिचित हों

33. लंबी अवधि चलने वाले ऑपरेशन्स को कैसे संभालते हैं?

असिंक्रोनस रिक्वेस्ट पैटर्न का उपयोग करें:

1. क्लाइंट रिक्वेस्ट भेजता है

2. सर्वर 202 Accepted के साथ एक स्टेटस URL लौटाता है

3. क्लाइंट पूर्णता तक स्टेटस URL को पोल करता है

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}संचालित द्वारा

34. Saga पैटर्न क्या है?

Saga माइक्रोसर्विसेज़ में बिना लॉकिंग के वितरित ट्रांज़ैक्शंस को संभालता है। हर सर्विस एक लोकल ट्रांज़ैक्शन चलाती है और एक इवेंट प्रकाशित करती है। यदि कोई स्टेप असफल हो, तो पिछली स्टेप्स को पूर्ववत करने के लिए compensating ट्रांज़ैक्शंस चलते हैं।

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel Orderसंचालित द्वारा

35. सामान्य JWT सुरक्षा कमज़ोरियाँ कौन-सी हैं?

Algorithm confusion: अटैकर RS256 को HS256 में बदल देता है और पब्लिक की से साइन करता है। समाधान: हमेशा एल्गोरिद्म्स को whitelist करें।

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])संचालित द्वारा

"none" एल्गोरिद्म: अटैकर सिग्नेचर पूरी तरह हटा देता है। समाधान: "none" एल्गोरिद्म को अस्वीकार करें।

बैकएंड डेवलपर REST API प्रश्न

36. N+1 क्वेरी समस्या क्या है?

N+1 समस्या तब होती है जब आप N रिकॉर्ड्स फेच करते हैं और प्रत्येक रिकॉर्ड के रिलेशनशिप के लिए अलग क्वेरी चलाते हैं।

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queriesसंचालित द्वारा

समाधान:

Django: फॉरेन कीज़ के लिए select_related(), और many-to-many के लिए prefetch_related() का उपयोग करें।

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()संचालित द्वारा

SQLAlchemy: joinedload() या selectinload() का उपयोग करें।

37. आप connection pooling कैसे कॉन्फ़िगर करते हैं?

Connection pooling हर रिक्वेस्ट पर नई कनेक्शन बनाने के बजाय डेटाबेस कनेक्शंस को पुन: उपयोग करता है।

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)संचालित द्वारा

38. आप कौन-सी कैशिंग स्ट्रैटेजीज़ जानते हैं?

तीन प्राथमिक कैशिंग स्ट्रैटेजीज़ हैं, जो अलग-अलग एक्सेस पैटर्न्स के लिए अनुकूलित हैं:

39. आप webhook signature verification कैसे लागू करते हैं?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)संचालित द्वारा

40. कौन-से मेट्रिक्स API की सेहत दर्शाते हैं?

API की सेहत जाँचने के लिए आपको ये चार प्रमुख मेट्रिक्स मॉनिटर करने चाहिए:

फुल स्टैक डेवलपर REST API प्रश्न

41. ब्राउज़र CORS preflight रिक्वेस्ट कब भेजता है?

ब्राउज़र OPTIONS preflight भेजते हैं जब:

• GET, HEAD, POST के अलावा अन्य methods हों
• कस्टम हेडर्स हों (Authorization, X-API-Key)
• Content-Type form-urlencoded, multipart/form-data, text/plain के अलावा हो

42. आप CORS को सुरक्षित रूप से कैसे कॉन्फ़िगर करते हैं?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));संचालित द्वारा

credentials के साथ कभी भी वाइल्डकार्ड (*) का उपयोग न करें। null origin की अनुमति कभी न दें।

43. क्लाइंट पर टोकन कहाँ स्टोर करने चाहिए?

टोकन स्टोरेज में XSS और CSRF कमजोरियों के बीच सुरक्षा trade-offs होते हैं"

श्रेष्ठ अभ्यास: रिफ्रेश टोकन्स को HttpOnly कुकीज़ में SameSite=Strict के साथ स्टोर करें। ऐक्सेस टोकन्स को मेमोरी में रखें।

44. WebSockets बनाम SSE कब उपयोग करने चाहिए?

चयन इस पर निर्भर करता है कि आपको दो-तरफ़ा संचार चाहिए या नहीं और आप reconnection कैसे संभालना चाहते हैं:

नोटिफिकेशंस, लाइव फ़ीड्स, स्टॉक टिकर्स के लिए SSE का उपयोग करें। चैट, मल्टीप्लेयर गेम्स, collaborative एडिटिंग के लिए WebSockets का उपयोग करें।

45. आप फ़ाइल अपलोड्स कैसे संभालते हैं?

बड़ी फ़ाइलों के लिए, प्रोग्रेस ट्रैकिंग के साथ chunked अपलोड्स का उपयोग करें:

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}संचालित द्वारा

परिदृश्य-आधारित REST API प्रश्न

46. एक होटल बुकिंग सिस्टम के लिए REST API डिज़ाइन करें

रिसोर्सेज़:

• /hotels - होटलों की सूची और सर्च

• /hotels/{id}/rooms - उपलब्ध कमरे

• /bookings - बुकिंग बनाना और मैनेज करना

• /guests/{id} - गेस्ट प्रोफाइल्स

मुख्य निर्णय:

• होटल सर्च के लिए cursor-आधारित pagination का उपयोग करें
• रूम उपलब्धता के लिए optimistic locking लागू करें
• डबल-बुकिंग प्रयासों के लिए 409 Conflict लौटाएँ
• पेमेंट प्रोसेसिंग के लिए idempotency keys का उपयोग करें

47. आप soft deletes कैसे लागू करेंगे?

रिकॉर्ड्स हटाने के बजाय deleted_at टाइमस्टैम्प जोड़ें:

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()संचालित द्वारा

48. आप v1 से v2 में बिना क्लाइंट्स को तोड़े कैसे माइग्रेट करेंगे?

Strangler Fig पैटर्न का उपयोग करें:

1. v2 को v1 के साथ-साथ डिप्लॉय करें
2. नई सुविधाओं को v2 पर रूट करें
3. मौजूदा एंडपॉइंट्स को धीरे-धीरे माइग्रेट करें
4. Sunset हेडर के माध्यम से deprecation कम्युनिकेट करें
5. माइग्रेशन अवधि के बाद v1 हटा दें

49. आप जटिल फ़िल्टरिंग के साथ सर्च API कैसे डिज़ाइन करेंगे?

कई फ़िल्टर्स वाले प्रोडक्ट सर्च के लिए:

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123संचालित द्वारा

डिज़ाइन निर्णय:

• फुल-टेक्स्ट सर्च के लिए Elasticsearch उपयोग करें (रिलेशनल DB फज़ी मैचिंग में संघर्ष करती हैं)
• उपलब्ध फ़िल्टर विकल्प दिखाने हेतु faceted सर्च लागू करें
• फ़िल्टर काउंट्स लौटाएँ ताकि यूज़र्स जान सकें हर फ़िल्टर कितने परिणाम देता है
• लोकप्रिय सर्च संयोजनों को कैश करें

50. माइक्रोसर्विस आर्किटेक्चर में आप API versioning कैसे संभालते हैं?

विकल्प:

1. गेटवे-लेवल वर्ज़निंग: API गेटवे /v1/* को पुरानी सेवाओं पर, और /v2/* को नई सेवाओं पर रूट करता है

2. सर्विस-लेवल वर्ज़निंग: प्रत्येक सर्विस अपना वर्ज़न नेगोशिएशन स्वयं संभालती है

3. कंज़्यूमर-ड्रिवन कॉन्ट्रैक्ट्स: Pact या समान टूल्स का उपयोग कर संगतता सुनिश्चित करें

अधिकतर टीमों के लिए, गेटवे-लेवल वर्ज़निंग सबसे साफ़ विभाजन प्रदान करती है।

51. अलग-अलग यूज़र टियर्स के लिए आप rate limiting कैसे लागू करेंगे?

समाधान में टियर-विशिष्ट लिमिट्स परिभाषित करना और उन्हें Redis काउंटर्स के जरिए जाँचना शामिल है:

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )संचालित द्वारा

व्यवहार-संबंधी REST API प्रश्न

52. किसी गैर-तकनीकी व्यक्ति को REST समझाएँ

"REST API को एक रेस्टोरेंट के वेटर की तरह समझें। आप (ग्राहक) सीधे किचन में नहीं जा सकते। इसके बजाय, आप वेटर को मेन्यू से बताते हैं कि आपको क्या चाहिए, और वह आपको लाकर देता है। मेन्यू API डॉक्यूमेंटेशन जैसा है, जो बताता है कि आप क्या ऑर्डर कर सकते हैं। वेटर कुछ नियमों का पालन करता है: आप कुछ माँगते हैं (GET), कुछ नया ऑर्डर करते हैं (POST), या कुछ वापस भेजते हैं (DELETE)। अगर किचन में कुछ नहीं है, तो वेटर आपको बता देता है (404 Not Found) ताकि आप बेवजह इंतज़ार न करें।"

यह उपमा स्टेकहोल्डर मीटिंग्स में आश्चर्यजनक रूप से अच्छी तरह काम करती है।

53. वह समय बताइए जब आपने किसी API को ऑप्टिमाइज़ किया

STAR विधि का उपयोग करें:

• स्थिति: "हमारे सर्च API को पीक ट्रैफिक में 3-सेकंड का रेस्पॉन्स टाइम लग रहा था"
• कार्य: "मुझे बड़े आर्किटेक्चर बदलाव के बिना लेटेंसी कम करनी थी"
• कार्रवाई: "मैंने बार-बार होने वाली क्वेरीज़ के लिए Redis कैशिंग जोड़ी, cursor-आधारित pagination लागू की, और डेटाबेस इंडेक्सेस ऐड किए"
• परिणाम: "रेस्पॉन्स टाइम 200ms पर आ गया, और हमने 5x अधिक ट्रैफिक हैंडल किया"

54. आप API consumers को breaking changes कैसे कम्युनिकेट करते हैं?

1. जल्दी घोषणा करें: बड़े बदलावों के लिए कम-से-कम 6-12 महीनों का नोटिस दें

2. Sunset हेडर उपयोग करें: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. माइग्रेशन गाइड्स दें: क्या बदला और कैसे अनुकूलित करें, यह स्पष्ट डॉक्यूमेंट करें

4. दोनों वर्ज़न्स चलाएँ: ट्रांज़िशन के दौरान पुराना वर्ज़न चालू रखें

5. उपयोग मॉनिटर करें: कौन-से क्लाइंट अब भी पुराने वर्ज़न पर हैं, इसे ट्रैक करें

55. आप APIs के लिए कौन-सी डॉक्यूमेंटेशन बनाते हैं?

आवश्यक डॉक्यूमेंटेशन में शामिल हैं:

• OpenAPI/Swagger स्पेक: मशीन-पठनीय कॉन्ट्रैक्ट
• Getting started गाइड: पाँच मिनट में पहला API कॉल
• Authentication गाइड: क्रेडेंशियल्स कैसे प्राप्त और उपयोग करें
• एरर रेफरेंस: सभी संभावित एरर कोड्स और उनका समाधान
• Changelog: प्रत्येक वर्ज़न में क्या बदला
• Rate limit डॉक्यूमेंटेशन: प्रति टियर लिमिट्स और 429 को कैसे हैंडल करें

56. आप कब REST का उपयोग नहीं करेंगे?

REST हमेशा सही विकल्प नहीं होता। विकल्पों का समय पर चयन करना आर्किटेक्चरल परिपक्वता दिखाता है। मैंने टीमों को ऐसे उपयोग मामलों में REST को ठूँसते देखा है जहाँ यह समस्याएँ बढ़ाता है।

REST API त्वरित संदर्भ

इस सेक्शन का उपयोग त्वरित लुकअप के रूप में करें जब भी आपको इंटरव्यू तैयारी या वास्तविक डेवलपमेंट के दौरान HTTP method प्रॉपर्टीज़, status codes, या सामान्य पैटर्न की पुष्टि करनी हो।

HTTP Methods तुलना

यह तालिका प्रत्येक HTTP method की मुख्य विशेषताओं का सार प्रस्तुत करती है, जो आपको अपने उपयोग मामले के लिए सही विकल्प चुनने में मदद करती है।

Status Codes संदर्भ

यहाँ सबसे आम HTTP status codes श्रेणी अनुसार दिए गए हैं। पूरी स्पेसिफिकेशन याद रखने के बजाय यह समझना अधिक महत्वपूर्ण है कि किसे कब उपयोग करना है।

2xx सफलता

• 200 OK: सफल GET, PUT, PATCH
• 201 Created: सफल POST (Location हेडर शामिल करें)
• 204 No Content: सफल DELETE

4xx क्लाइंट त्रुटियाँ

• 400 Bad Request: गलत सिंटैक्स
• 401 Unauthorized: प्रमाणीकरण आवश्यक
• 403 Forbidden: authenticated पर अधिकृत नहीं
• 404 Not Found: रिसोर्स मौजूद नहीं
• 409 Conflict: स्टेट संघर्ष
• 422 Unprocessable Entity: वैलिडेशन एरर
• 429 Too Many Requests: रेट लिमिटेड

5xx सर्वर त्रुटियाँ

• 500 Internal Server Error: सामान्य सर्वर विफलता
• 502 Bad Gateway: अपस्ट्रीम सर्वर त्रुटि
• 503 Service Unavailable: अस्थायी रूप से ओवरलोडेड

सामान्य गलतियाँ जिनसे बचें

अनुभवी डेवलपर्स भी इन जालों में फँस जाते हैं। REST APIs डिज़ाइन या लागू करते समय इन सामान्य गलतियों से सावधान रहें:

• URLs में verbs का उपयोग (जैसे /getUsers की जगह /users)

• एरर स्टेट्स के लिए 200 OK लौटाना, जिससे क्लाइंट-साइड एरर हैंडलिंग टूटती है

• 401 और 403 में भ्रम (Authentication बनाम Authorization)

• URLs को अत्यधिक नेस्ट करना दो स्तर से ज़्यादा

• localStorage में टोकन्स स्टोर करना (XSS कमजोरियाँ पैदा करता है)

• POST रिक्वेस्ट्स के लिए idempotency की अनदेखी

• कार्रवाई योग्य विवरणों के बिना सामान्य एरर संदेश लौटाना

निष्कर्ष

मैं मानता हूँ कि परिभाषाएँ रट लेना हर तकनीकी इंटरव्यू पास कराने की गारंटी नहीं है। वास्तविकता यह है कि प्रोडक्शन इंजीनियरिंग में हम अक्सर उन "कड़े" नियमों को तोड़ते हैं जिन पर अभी चर्चा हुई, और इंटरव्यूअर आपकी तर्क-क्षमता को आपकी RFC स्पेसिफिकेशंस सुनाने की क्षमता से अधिक महत्व देते हैं। अत्यधिक विशिष्ट भूमिकाओं में, गहरे डोमेन ज्ञान या किसी विशेष फ्रेमवर्क की विशेषज्ञता निर्णायक कारक हो सकती है।

लेकिन इन REST मूलभूतों में महारत आवश्यक है, भले ही आपसे ठीक-ठीक यही प्रश्न न पूछे जाएँ। यह समझने का एक ब्लूप्रिंट है कि आधुनिक वेब कैसे काम करता है। जब आपसे नया सिस्टम डिज़ाइन करने या प्रोडक्शन आउटेज डिबग करने को कहा जाएगा, तो 401 और 403 के अंतर (जैसा कि मैंने पहले समझाया) को समझना आपको समस्याएँ तेज़ी से सुलझाने में स्पष्टता देगा। आप समझेंगे कि अपने API इंटरेक्शंस को मानकीकृत करना—सिर्फ़ "चलता है" कोड लिखना नहीं—सीनियर इंजीनियर की पहचान है।

यदि आप इन सिस्टम्स को और गहराई से बनाना चाहते हैं, तो हमारा Introduction to APIs in Python कोर्स देखें।