REST API प्रश्न यह जाँचते हैं कि आप ऐसा इंटरफ़ेस डिज़ाइन कर सकते हैं जिसे दूसरे बिना किसी आश्चर्य के इस्तेमाल कर सकें। नीचे 20 प्रश्न उत्तरों के साथ दिए गए हैं, बुनियादी बातों से लेकर उन डिज़ाइन विवरणों तक जो बैकएंड और फुल-स्टैक इंटरव्यू में आते हैं। HTTP मेथड नियमों के लिए, हमने RFC 9110 में दी गई परिभाषाओं का पालन किया है।
बुनियादी बातें
1. REST क्या है?
REST नेटवर्क्ड सिस्टम के लिए एक आर्किटेक्चरल शैली है, जो URL से पहचाने जाने वाले रिसोर्स के इर्द-गिर्द बनी होती है, जिन्हें कुछ मानक ऑपरेशनों के छोटे सेट से संचालित किया जाता है, और JSON जैसी रिप्रेज़ेंटेशन से वर्णित किया जाता है। एक REST API स्टेटलेस होती है: हर रिक्वेस्ट में वह सब होता है जो सर्वर को उसे संभालने के लिए चाहिए, इसलिए कोई भी सर्वर किसी भी रिक्वेस्ट को पूरा कर सकता है।
2. व्यवहार में किसी API को "RESTful" क्या बनाता है?
- URL में रिसोर्स के लिए संज्ञा, जैसे /orders/42, न कि /getOrder जैसी क्रियाएँ
- कार्यों के लिए मानक HTTP मेथड
- अर्थपूर्ण स्टेटस कोड
- स्टेटलेस रिक्वेस्ट
- एक जैसी रिप्रेज़ेंटेशन और एरर शेप
इंटरव्यू में कहें कि बहुत कम असली API हर REST बाधा का पालन करती हैं, और आपका लक्ष्य अनुमानित व्यवहार है।
3. मुख्य HTTP मेथड किस लिए इस्तेमाल होते हैं?
| मेथड | उपयोग | सेफ | आइडेम्पोटेंट |
|---|---|---|---|
| GET | रिसोर्स पढ़ना | हाँ | हाँ |
| POST | रिसोर्स बनाना या कोई कार्य ट्रिगर करना | नहीं | नहीं |
| PUT | रिसोर्स को बदलना | नहीं | हाँ |
| PATCH | रिसोर्स को आंशिक रूप से अपडेट करना | नहीं | गारंटी नहीं |
| DELETE | रिसोर्स हटाना | नहीं | हाँ |
"सेफ" का मतलब है कि रिक्वेस्ट सर्वर की स्थिति नहीं बदलती। "आइडेम्पोटेंट" का मतलब है कि इसे कई बार भेजने का असर एक बार भेजने जितना ही होता है।
4. आइडेम्पोटेंट का क्या मतलब है, और यह क्यों मायने रखता है?
अगर कोई रिक्वेस्ट दोहराई जाए, तो अंतिम स्थिति एक रिक्वेस्ट के बाद जैसी होती, वैसी ही रहती है। यह मायने रखता है क्योंकि नेटवर्क फेल होते हैं। अगर किसी PUT पर क्लाइंट का टाइमआउट हो जाए, तो वह बिना डर के दोबारा कोशिश कर सकता है। ऑर्डर बनाने वाला POST दो ऑर्डर बना सकता है, इसलिए API अक्सर आइडेम्पोटेंसी की मानती है: क्लाइंट एक यूनिक की भेजता है, और अगर सर्वर को वह की दोबारा दिखे तो वह सेव किया गया नतीजा लौटा देता है।
5. PUT या PATCH?
PUT पूरे रिसोर्स को उस बॉडी से बदल देता है जो आप भेजते हैं, और जो फ़ील्ड आप छोड़ देते हैं वे हटा या रीसेट कर दिए जाते हैं। PATCH सिर्फ़ उन फ़ील्ड को बदलता है जो आप भेजते हैं। छोटे अपडेट के लिए PATCH और तब PUT इस्तेमाल करें जब क्लाइंट के पास पूरी रिप्रेज़ेंटेशन हो।
स्टेटस कोड और एरर
6. आप कौन से स्टेटस कोड कब इस्तेमाल करते हैं?
| कोड | उपयोग |
|---|---|
| 200 | बॉडी के साथ सफलता |
| 201 | बनाया गया, नए रिसोर्स के लिए Location हेडर के साथ |
| 204 | बिना बॉडी सफलता, जैसे कोई डिलीट |
| 400 | रिक्वेस्ट खराब या अमान्य है |
| 401 | ऑथेंटिकेट नहीं है |
| 403 | ऑथेंटिकेट है पर अनुमति नहीं है |
| 404 | रिसोर्स नहीं मिला |
| 409 | मौजूदा स्थिति से टकराव, जैसे कोई डुप्लिकेट |
| 422 | ठीक बनी है पर वैलिडेशन फेल होती है |
| 429 | बहुत ज़्यादा रिक्वेस्ट |
| 500 | सर्वर एरर |
| 503 | सेवा उपलब्ध नहीं |
एक आम फ़ॉलो-अप सवाल 401 और 403 के फ़र्क़ के बारे में होता है। 401 का मतलब है "मुझे नहीं पता आप कौन हैं", और 403 का मतलब है "मुझे पता है आप कौन हैं, और आप यह नहीं कर सकते"।
7. किसी API को एरर कैसे लौटाने चाहिए?
सही स्टेटस कोड और एक जैसी बॉडी इस्तेमाल करें। एक अच्छी एरर बॉडी में एक स्थिर मशीन-पठनीय कोड, एक मानव-पठनीय संदेश, और वैलिडेशन एरर के लिए यह भी होता है कि कौन से फ़ील्ड फेल हुए। क्लाइंट को स्टैक ट्रेस या आंतरिक विवरण न दें।
8. आप वैलिडेशन कैसे संभालते हैं?
भले ही क्लाइंट भी वैलिडेट करे, सर्वर पर वैलिडेट करें। जब हो सके तो सारी समस्याएँ एक साथ लौटाएँ, ताकि उपयोगकर्ता उन्हें एक-एक करके ठीक न करे, और 400 या 422 लगातार इस्तेमाल करें।
डिज़ाइन
9. रिलेशनशिप के लिए URL कैसे डिज़ाइन करते हैं?
जब चाइल्ड रिसोर्स सिर्फ़ पैरेंट के अंदर ही मायने रखता हो, तो उसे नेस्ट करें, जैसे /users/7/orders। नेस्टिंग उथली रखें। एक-दो लेवल से ज़्यादा होने पर चाइल्ड को सीधे एक्सपोज़ करें, जैसे /orders/42, और क्वेरी पैरामीटर से फ़िल्टर करें, जैसे /orders?userId=7।
10. लिस्ट को पेजिनेट कैसे करते हैं?
| तरीका | यह कैसे काम करता है | ट्रेड-ऑफ़ |
|---|---|---|
| ऑफ़सेट और लिमिट | ?offset=40&limit=20 | सरल है, लेकिन बड़ी टेबल्स पर धीमा और डेटा बदलने पर आइटम छूट या दोहरा सकते हैं |
| कर्सर | ?after=<token>&limit=20 | स्थिर और तेज़, लेकिन आप सीधे पेज 50 पर नहीं जा सकते |
| पेज नंबर | ?page=3 | UI के लिए आसान, पर ऑफ़सेट जैसी ही समस्याएँ |
बड़े या तेज़ी से बदलने वाले डेटा के लिए आमतौर पर कर्सर पेजिनेशन ही जवाब है। अगला कर्सर और यह संकेत लौटाएँ कि आगे और नतीजे हैं या नहीं।
11. फ़िल्टर और सॉर्ट कैसे करते हैं?
क्वेरी पैरामीटर इस्तेमाल करें, जैसे ?status=open&sort=-created_at। जिन फ़ील्ड्स की अनुमति देते हैं उनकी व्हाइटलिस्ट बनाएँ, ताकि बिना इंडेक्स वाले या संवेदनशील कॉलम एक्सपोज़ न हों और क्वेरी तेज़ बनी रहे।
12. API को वर्ज़न कैसे करते हैं?
| तरीका | उदाहरण | नोट |
|---|---|---|
| URL में | /v2/orders | सरल और साफ़ दिखता है |
| हेडर में | Accept: application/vnd.example.v2+json | URL साफ़ रहते हैं, ब्राउज़र में टेस्ट करना मुश्किल |
| क्वेरी पैरामीटर | ?version=2 | आसान, पर भूलना भी आसान |
आप जो भी चुनें, एक वर्ज़न के अंदर ब्रेकिंग चेंज से बचें। फ़ील्ड जोड़ना आमतौर पर सुरक्षित होता है, और फ़ील्ड हटाना या नाम बदलना नहीं।
13. HATEOAS क्या है?
जवाबों में जुड़ी हुई कार्रवाइयों के लिंक शामिल होते हैं, ताकि क्लाइंट URL हार्ड-कोड करने के बजाय खुद पता लगा सके कि आगे क्या कर सकता है। यह REST की परिभाषा का हिस्सा है, लेकिन कुछ ही APIs इसे पूरी तरह लागू करते हैं। कहें कि आप इसे जानते हैं और ज़्यादातर टीमें इसके बजाय डॉक्युमेंटेशन और OpenAPI डिस्क्रिप्शन इस्तेमाल करती हैं।
सुरक्षा और परफ़ॉर्मेंस
14. API को ऑथेंटिकेट कैसे करते हैं?
आम विकल्प हैं — साधारण सर्वर-टू-सर्वर इस्तेमाल के लिए API keys, JSON Web Tokens जैसे bearer tokens, और OAuth 2.0 जब कोई यूज़र किसी ऐप को अपने डेटा तक पहुँच देता है। हमेशा HTTPS इस्तेमाल करें। सीक्रेट्स URLs में न रखें, क्योंकि URLs लॉग्स में पहुँच जाते हैं।
15. ऑथेंटिकेशन और ऑथराइज़ेशन में क्या फ़र्क़ है?
ऑथेंटिकेशन यह साबित करना है कि आप कौन हैं। ऑथराइज़ेशन यह तय करना है कि आपको क्या करने की अनुमति है। दोनों अलग तरह से फेल होते हैं: टोकन गायब या अमान्य हो तो 401, और टोकन सही हो पर अनुमति न हो तो 403।
16. API को दुरुपयोग से कैसे बचाते हैं?
हर key या IP पर रेट लिमिटिंग, रिक्वेस्ट साइज़ की सीमाएँ, इनपुट वैलिडेशन, टाइमआउट, और असामान्य ट्रैफ़िक की निगरानी। 429 के साथ Retry-After हेडर लौटाएँ ताकि क्लाइंट्स को पता चले कि दोबारा कब कोशिश करनी है।
17. APIs के लिए HTTP कैशिंग कैसे काम करती है?
जवाबों में Cache-Control हेडर हो सकते हैं जो बताते हैं कि रिस्पॉन्स कितनी देर दोबारा इस्तेमाल किया जा सकता है। ETag रिस्पॉन्स के एक वर्ज़न की पहचान करता है। क्लाइंट उसे If-None-Match में वापस भेजता है, और अगर कुछ नहीं बदला तो सर्वर बिना बॉडी के 304 Not Modified लौटाता है। इससे बैंडविड्थ और लोड बचता है।
18. CORS क्या है?
ब्राउज़र किसी वेब पेज को अलग ओरिजिन से आए जवाब पढ़ने से रोकते हैं, जब तक सर्वर अनुमति न दे। सर्वर Access-Control-Allow-Origin जैसे हेडर भेजता है ताकि बताए कि कौन-से ओरिजिन उसके जवाब पढ़ सकते हैं। इसे ब्राउज़र लागू करता है, सर्वर नहीं, इसलिए यह API को नॉन-ब्राउज़र क्लाइंट्स से नहीं बचाता।
व्यावहारिक
19. REST या GraphQL या gRPC?
| किसके लिए अच्छा | कीमत | |
|---|---|---|
| REST | सरल, कैश करने योग्य, व्यापक रूप से समझे जाने वाले पब्लिक APIs | जटिल स्क्रीन के लिए ज़रूरत से ज़्यादा डेटा और कई राउंड ट्रिप |
| GraphQL | ऐसे क्लाइंट जिन्हें ठीक-ठीक फ़ील्ड चुनने और एक ही रिक्वेस्ट में डेटा जोड़ने की ज़रूरत हो | सर्वर पर ज़्यादा जटिलता और कैशिंग मुश्किल |
| gRPC | सख़्त कॉन्ट्रैक्ट वाली तेज़ इंटरनल सर्विस-टू-सर्विस कॉल्स | ब्राउज़र और पब्लिक इस्तेमाल के लिए कम अनुकूल |
सबसे अच्छा जवाब किसी स्थिति का नाम लेता है, विजेता का नहीं।
20. API को डॉक्युमेंट और टेस्ट कैसे करते हैं?
इसे OpenAPI स्पेसिफिकेशन से बताएँ, जिससे डॉक्युमेंटेशन और क्लाइंट कोड बनाया जा सकता है। तीन स्तरों पर टेस्ट करें: लॉजिक के लिए यूनिट टेस्ट, असली डेटाबेस के ख़िलाफ़ इंटीग्रेशन टेस्ट, और ब्रेकिंग चेंज पकड़ने के लिए कॉन्ट्रैक्ट टेस्ट। फेल होने वाले केस भी आज़माएँ, जैसे अमान्य इनपुट और एक्सपायर हो चुके टोकन।
तैयारी कैसे करें
- व्हाइटबोर्ड पर छोटा API डिज़ाइन कर पाना चाहिए, जैसे टू-डू लिस्ट या ऑर्डर सिस्टम, URLs, मेथड्स, स्टेटस कोड्स और एक एरर रिस्पॉन्स के साथ।
- इडेम्पोटेंसी और पेजिनेशन अच्छी तरह याद रखें। यही सबसे ज़्यादा पूछे जाते हैं।
- अपने बनाए या इस्तेमाल किए किसी API की एक कहानी तैयार रखें, और एक गलती जो अगली बार नहीं दोहराएँगे।
और अभ्यास के लिए हमारी गाइड देखें: Spring Boot interview questions, Node.js interview questions, system design interview questions, और computer networking interview questions।
ज़ोर से और अपने शब्दों में अभ्यास करें। बाद में ट्रांसक्रिप्ट देखने से पता चलता है कि कहाँ भटके या मुद्दा छोड़ दिया। किसी भी लाइव इंटरव्यू या असेसमेंट में AI टूल्स को लेकर एम्प्लॉयर के नियमों का पालन करें।
YesToTheOffer के साथ अपने उत्तरों का अभ्यास करें
जोर से अभ्यास करें, अपने ही रिज्यूमे से उत्तर प्राप्त करें, और बाद में अपने ट्रांसक्रिप्ट की समीक्षा करें। 30 मुफ्त मिनट, कोई सदस्यता नहीं।
