इंडस्ट्री में, एकीकरण एप्लिकेशन डिज़ाइन में महत्वपूर्ण भूमिका निभाते हैं। इसके लिए मुख्य तकनीकों में से एक है। REST API का ज्ञान हर तकनीकी विशेषज्ञ के लिए एक महत्वपूर्ण कौशल है। इस लेख में, हम 25 REST API प्रश्न प्रस्तुत करेंगे जो आपको नौकरी के साक्षात्कार के लिए तैयार होने और अपने कौशल को बेहतर बनाने में मदद करेंगे। पढ़ने का आनंद लें! सॉफ़्टवेयर डेवलपमेंट REST API सबसे पहले, साक्षात्कारकर्ता आमतौर पर REST API पर प्रश्नों को सैद्धांतिक और व्यावहारिक में विभाजित करता है। सबसे पहले, वे शब्दावली और HTTP अनुरोध विधियों पर 2-3 सैद्धांतिक प्रश्न पूछते हैं, और फिर आपको अनुरोध तैयार करने पर एक व्यावहारिक कार्य मिलता है। इस लेख में अक्सर पूछे जाने वाले सैद्धांतिक प्रश्न शामिल हैं, और मैं अगले लेख में REST API से संबंधित व्यावहारिक कार्यों के उदाहरण प्रकाशित करने की योजना बना रहा हूँ। हम पहले से नहीं जानते कि साक्षात्कार में आपसे क्या प्रश्न पूछे जाएँगे, लेकिन मुझे यकीन है कि हमारे विशिष्ट प्रश्नों की सूची के माध्यम से काम करने की प्रक्रिया में, आप शायद विषय में गहराई से उतरेंगे, और किसी भी मामले में REST API के बारे में अपने ज्ञान में सुधार करेंगे। अब, आइए सरल से जटिल की ओर बढ़ें, बुनियादी शब्दावली से शुरू करते हुए अधिक जटिल प्रश्नों वाले अनुभाग पर आगे बढ़ें। 1. REST क्या है? उत्तर: REST का उल्लेख करते समय तीन शब्दों का उपयोग किया जाता है जिन्हें अक्सर एक ही चीज़ माना जाता है, लेकिन यह पूरी तरह से सच नहीं है। ये शब्द हैं REST, REST API और RESTful API। अब REST के बारे में एक उत्तर होगा, यह शब्द रिप्रेजेंटेशनल स्टेट ट्रांसफर के लिए है और यह HTTP प्रोटोकॉल (हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल) पर आधारित एक आर्किटेक्चरल स्टाइल है, जो ऐसे एप्लिकेशन विकसित करने के लिए है जिनमें फ्रंट-एंड और/या बाहरी सिस्टम के साथ एकीकरण है। REST उन दिशा-निर्देशों का वर्णन करता है जिनका पालन API सेवाओं को करना चाहिए। ये सिद्धांत सुनिश्चित करते हैं कि HTTP का उपयोग करके क्लाइंट और सर्वर के बीच अनुरोध पारित किए जाते हैं। 2. REST API क्या है? उत्तर: API एक प्रोग्रामिंग इंटरफ़ेस है जो व्यक्तिगत अनुप्रयोगों को संचार और डेटा का आदान-प्रदान करने की अनुमति देता है। उदाहरण के लिए, एक खाद्य वितरण ऐप कूरियर के स्थान को ट्रैक करने और उसे मानचित्र पर प्रदर्शित करने के लिए Google मैप्स API का उपयोग कर सकता है। REST API एक API है जो REST के सिद्धांतों का पालन करता है, सभी डेटा को संसाधनों के रूप में मानता है, प्रत्येक को एक अद्वितीय यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) द्वारा दर्शाया जाता है। 3. रेस्टफुल एपीआई क्या है? उत्तर: RESTful API एक API है जिसे REST के नियमों (या आप इसे “सिद्धांत” भी कह सकते हैं) के अनुसार डिज़ाइन किया गया है। दूसरे शब्दों में, REST API और RESTful API के बीच का अंतर शब्दावली है। पहला मामला REST नियमों के एक सेट को संदर्भित करता है, और दूसरा REST नियमों का पालन करते हुए एक विशिष्ट API के कार्यान्वयन को संदर्भित करता है। संक्षिप्तता के लिए RESTful API शब्द को अक्सर REST API या यहाँ तक कि REST से बदल दिया जाता है। जब सिस्टम विश्लेषक किसी एप्लिकेशन आरेख पर REST लेबल वाले तीर खींचते हैं, तो उनका मतलब RESTful API होता है। 4. REST के दो मुख्य सिद्धांत क्या हैं? उत्तर: REST API अनुरोधों को दो बुनियादी सिद्धांतों का पालन करना चाहिए: क्लाइंट और सर्वर में विभाजन: क्लाइंट और सर्वर के बीच बातचीत अनुरोधों और प्रतिक्रियाओं के रूप में की जाती है। केवल क्लाइंट ही अनुरोध कर सकते हैं और केवल सर्वर ही एक दूसरे से स्वतंत्र रूप से काम करने के लिए प्रतिक्रियाएँ भेज सकते हैं। एकल प्रोटोकॉल: क्लाइंट और सर्वर के बीच बातचीत एक ही प्रोटोकॉल का उपयोग करके की जानी चाहिए। REST के लिए, यह प्रोटोकॉल HTTP है। 5. REST के अन्य कौन से सिद्धांत आप जानते हैं? उत्तर: आप कम से कम 4 और सिद्धांतों का नाम दे सकते हैं। REST API अनुरोध सर्वर पर स्थिति संग्रहीत नहीं करते हैं और सर्वर की परतों से गुजर सकते हैं और कैश किए जा सकते हैं। आप सर्वर प्रतिक्रिया में ग्राहकों को निष्पादन योग्य कोड भी भेज सकते हैं। सर्वर स्टेटलेस: सर्वर पिछले अनुरोधों/प्रतिक्रियाओं के बारे में कोई जानकारी संग्रहीत नहीं करता है। प्रत्येक अनुरोध और प्रतिक्रिया में इंटरैक्शन को पूरा करने के लिए आवश्यक सभी जानकारी होती है। स्टेटलेस संचार सर्वर लोड को कम करता है, मेमोरी बचाता है, और प्रदर्शन में सुधार करता है। स्तरित प्रणाली: विभिन्न कार्यों को करने के लिए परतों के रूप में क्लाइंट और API सर्वर के बीच अतिरिक्त सर्वर संभव हैं। REST सिद्धांतों पर निर्मित प्रणाली में, परतें मॉड्यूलर होती हैं और क्लाइंट और सर्वर के बीच संचार को प्रभावित किए बिना उन्हें जोड़ा और हटाया जा सकता है। कैशेबिलिटी: सर्वर की प्रतिक्रियाएं इंगित करती हैं कि इसका संसाधन कैश करने योग्य है 6. संसाधन क्या है? उत्तर: REST में, सर्वर साइड पर हर सुलभ ऑब्जेक्ट को संसाधन के रूप में नामित किया जाता है। संसाधन एक ऑब्जेक्ट है जिसका एक प्रकार, उससे जुड़ा डेटा, सर्वर पर अन्य संसाधनों से संबंध और उसके साथ काम करने के लिए इस्तेमाल की जा सकने वाली विधियों की एक सूची होती है। उदाहरण के लिए, एक संसाधन एक HTML या टेक्स्ट फ़ाइल, एक डेटा फ़ाइल, एक छवि या वीडियो या एक निष्पादन योग्य कोड फ़ाइल हो सकता है। एक संसाधन की पहचान एक यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर या URI द्वारा की जाती है। क्लाइंट HTTP अनुरोधों में अपने URI का उपयोग करके संसाधनों तक पहुँचते हैं। 7. यूआरएल क्या है? उत्तर: URI का मतलब यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर है। यह एक स्ट्रिंग है जो सर्वर पर किसी संसाधन की पहचान करती है। प्रत्येक संसाधन का अपना अनूठा URI होता है, जिसे HTTP अनुरोध में शामिल करने पर क्लाइंट उस संसाधन तक पहुँच सकते हैं और उस पर कार्य कर सकते हैं। किसी संसाधन को उसके URI द्वारा संदर्भित करने की प्रक्रिया को "एड्रेसिंग" कहा जाता है। 8. सीआरयूडी क्या है? उत्तर: CRUD का मतलब है "क्रिएट, रीड, अपडेट, डिलीट"। ये चार मुख्य क्रियाएँ हैं जो REST API के माध्यम से डेटाबेस पर की जा सकती हैं। प्रत्येक क्रिया की अपनी HTTP अनुरोध विधि होती है: बनाएं = पोस्ट करें पढें = प्राप्त करें अद्यतन = डाल मिटाना = हटाएँ 9. सर्वर प्रतिक्रिया में पेलोड से क्या तात्पर्य है? उत्तर: HTTP प्रतिक्रिया पेलोड क्लाइंट द्वारा अनुरोधित संसाधन डेटा को संदर्भित करता है। इसे संक्षेप में "HTTP प्रतिक्रिया पेलोड" भी कहा जाता है। यह डेटा JSON, XML, HTML, छवियों, फ़ाइलों आदि में हो सकता है, जो इस बात पर निर्भर करता है कि सर्वर वास्तव में क्या प्रदान करता है। 10. REST मैसेजिंग क्या है? उत्तर: REST में मैसेजिंग क्लाइंट और सर्वर के बीच संदेशों के आदान-प्रदान को संदर्भित करता है। संचार हमेशा क्लाइंट द्वारा सर्वर को HTTP अनुरोध करने से शुरू होता है। सर्वर इस अनुरोध को संसाधित करता है और फिर एक HTTP प्रतिक्रिया भेजता है जो अनुरोध की स्थिति और क्लाइंट द्वारा अनुरोधित किसी भी संसाधन को इंगित करता है। 11. REST में मैसेज ब्रोकर क्या है? उत्तर: REST के संदर्भ में, "संदेश ब्रोकर" शब्द एक मिडलवेयर है जो वितरित एप्लिकेशन में विभिन्न घटकों या प्रणालियों के बीच संदेशों को पास करने का काम करता है। ब्रोकर विभिन्न सिस्टम मॉड्यूल के बीच अतुल्यकालिक डेटा एक्सचेंज, संदेश कतार और संदेश प्रसंस्करण प्रदान कर सकता है। मैसेज ब्रोकर का उपयोग एसिंक्रोनस ऑपरेशन को प्रबंधित करने या नोटिफिकेशन भेजने के लिए किया जा सकता है। मैसेज ब्रोकर एक मूल REST तत्व नहीं है क्योंकि... REST HTTP अनुरोधों का उपयोग करके क्लाइंट और सर्वर के बीच सिंक्रोनस संचार पर ध्यान केंद्रित करता है। 12. REST द्वारा कौन सी HTTP अनुरोध विधियाँ समर्थित हैं? उत्तर: HTTP अनुरोध विधि वांछित क्रिया को निर्दिष्ट करती है जिसे सर्वर संसाधन पर निष्पादित करेगा। REST में, क्लाइंट से सर्वर तक HTTP अनुरोध करने के लिए चार मुख्य विधियाँ हैं: GET: सर्वर से संसाधन का अनुरोध करता है, यह विधि केवल पढ़ने के लिए है। POST: सर्वर पर एक नया संसाधन बनाता है। PUT: सर्वर पर मौजूदा संसाधन को अद्यतन करता है। हटाएँ: सर्वर से संसाधन हटाता है। 13. POST और PUT विधियों में क्या अंतर है? उत्तर: POST सर्वर पर एक संसाधन बनाने के लिए है जबकि PUT किसी विशिष्ट URI पर किसी संसाधन को दूसरे संसाधन से बदलने के लिए है। यदि आप किसी ऐसे URI पर PUT का उपयोग करते हैं जिसके साथ पहले से ही कोई संसाधन संबद्ध है, तो PUT उसे बदल देगा। यदि निर्दिष्ट URI पर कोई संसाधन नहीं है, तो PUT एक संसाधन बनाता है। PUT आइडेम्पोटेंट है, जिसका अर्थ है कि इसे कई बार कॉल करने से केवल एक संसाधन ही बनेगा। ऐसा इसलिए होता है क्योंकि प्रत्येक कॉल एक मौजूदा संसाधन को बदल देता है (या अगर बदलने के लिए कुछ नहीं है तो एक नया संसाधन बनाता है)। POST आइडेम्पोटेंट नहीं है। यदि, उदाहरण के लिए, आप POST को 10 बार कॉल करते हैं, तो सर्वर पर 10 अलग-अलग संसाधन बनाए जाएंगे, जिनमें से प्रत्येक का अपना URI होगा। हालाँकि शायद ही कभी इस्तेमाल किया जाता है, POST प्रतिक्रियाओं को कैश किया जा सकता है, लेकिन PUT प्रतिक्रियाओं को नहीं। POST अनुरोधों को आम तौर पर अनकैचेबल माना जाता है, लेकिन उन्हें तब कैश किया जा सकता है जब उनमें डेटा की "ताज़गी" के बारे में स्पष्ट जानकारी हो। अधिक विस्तृत उत्तर यह है कि यदि डेटा "ताज़ा" है और Content-Location (en-US) हेडर सेट है, तो POST (या PATCH) अनुरोध के लिए प्रतिक्रिया को कैश किया जा सकता है, लेकिन यह शायद ही कभी लागू किया जाता है। इसलिए, यदि संभव हो तो POST कैशिंग से बचना चाहिए। 14. HTTP अनुरोध के मुख्य भाग क्या हैं? उत्तर: REST में, HTTP अनुरोध के निम्नलिखित मूल घटक हैं: संसाधन के लिए किया जाने वाला अनुरोध तरीका (यानी GET, POST, PUT, DELETE)। एक URI जो सर्वर पर अनुरोधित संसाधन की पहचान करता है। HTTP संस्करण - यानी सर्वर प्रतिक्रिया में कौन सा संस्करण होना चाहिए। HTTP अनुरोध हेडर में अनुरोध के बारे में मेटाडेटा होता है, जैसे कि उपयोगकर्ता एजेंट, क्लाइंट द्वारा स्वीकार किए गए फ़ाइल प्रारूप, अनुरोध बॉडी प्रारूप, भाषा, कैशिंग प्राथमिकताएँ, आदि। HTTP अनुरोध का मुख्य भाग, इसमें अनुरोध से जुड़ा सारा डेटा होता है। यह केवल तभी आवश्यक है जब अनुरोध POST या PUT विधियों का उपयोग करके सर्वर पर डेटा बदलने का हो। 15. HTTP प्रतिक्रिया के मुख्य भाग क्या हैं? उत्तर: HTTP प्रतिक्रियाएँ सर्वर से क्लाइंट को भेजी जाती हैं। वे क्लाइंट को सूचित करते हैं कि अनुरोधित कार्रवाई पूरी हो गई है (या नहीं हुई है) और किसी भी अनुरोधित संसाधन की डिलीवरी हो गई है। HTTP प्रतिक्रिया के चार मुख्य घटक हैं: उपयोग किया गया HTTP संस्करण। अनुरोध स्थिति और HTTP प्रतिक्रिया स्थिति कोड के साथ स्थिति पट्टी। प्रतिक्रिया के बारे में मेटाडेटा के साथ HTTP प्रतिक्रिया हेडर, जिसमें समय, सर्वर नाम, उपयोगकर्ता एजेंट, लौटाए गए संसाधन फ़ाइल प्रारूप, कैशिंग जानकारी शामिल है। HTTP प्रतिक्रिया बॉडी जिसमें क्लाइंट द्वारा अनुरोधित संसाधन के बारे में डेटा होता है 16. सफल HTTP सर्वर प्रतिक्रियाओं के लिए कम से कम 3 कोड बताएं उत्तर: अनुरोध सफलतापूर्वक संसाधित होने पर सर्वर निम्नलिखित ऑपरेशन स्थिति कोड लौटाता है: 200 ठीक: अनुरोध सफलतापूर्वक पूरा हो गया. 201 निर्मित: अनुरोध सफल रहा और संसाधन निर्मित हो गया। 202 स्वीकृत: इस स्थिति का मतलब है कि सर्वर ने क्लाइंट के अनुरोध को स्वीकार कर लिया है, लेकिन इसकी प्रोसेसिंग पूरी नहीं की है। प्रोसेसिंग एसिंक्रोनस हो सकती है। 17. किसी अनुरोध को पुनर्निर्देशित करते समय कम से कम 4 सर्वर HTTP प्रतिक्रिया कोड का नाम बताएं उत्तर: अनुरोध को पुनर्निर्देशित करते समय सर्वर निम्नलिखित स्थिति कोड लौटाता है: 301 स्थायी रूप से स्थानांतरित: यह स्थिति क्लाइंट को बताती है कि अनुरोधित संसाधन को स्थायी रूप से किसी अन्य URL पर स्थानांतरित कर दिया गया है और क्लाइंट को संसाधन तक पहुंचने के लिए नए URL तक पहुंचना होगा। 302 पाया गया: यह स्थिति इंगित करती है कि संसाधन को अस्थायी रूप से किसी अन्य URL पर ले जाया गया है और क्लाइंट को अस्थायी रूप से नए URL का उपयोग करना चाहिए। 307 अस्थायी रीडायरेक्ट: 302 के समान, लेकिन नए URL तक पहुँचने के लिए क्लाइंट को समान अनुरोध विधि का उपयोग करना होगा। 308 स्थायी रीडायरेक्ट: 301 के समान, लेकिन नए URL तक पहुँचने के लिए क्लाइंट को समान अनुरोध विधि का उपयोग करना होगा 18. असफल HTTP सर्वर प्रतिक्रियाओं के लिए कम से कम 4 कोड बताएं। उत्तर: अनुरोध असफल होने पर सर्वर निम्नलिखित कोड लौटाता है: 400 गलत अनुरोध: अनुरोध में किसी त्रुटि के कारण अनुरोध पूरा नहीं हुआ, जैसे टाइपिंग त्रुटि या डेटा का अभाव। 401 अनधिकृत: अनुरोध पूरा नहीं हुआ क्योंकि क्लाइंट प्रमाणित नहीं है या उसके पास अनुरोधित संसाधन तक पहुंचने की अनुमति नहीं है। 403 निषिद्ध: अनुरोध पूरा नहीं हुआ क्योंकि क्लाइंट प्रमाणित है लेकिन अनुरोधित संसाधन तक पहुंचने के लिए अधिकृत नहीं है। 404 नहीं मिला: अनुरोध पूरा नहीं हुआ क्योंकि सर्वर अनुरोधित संसाधन नहीं ढूंढ सका। 19. कम से कम 3 सर्वर त्रुटि कोड बताएं। उत्तर: जब सर्वर पर कोई त्रुटि होती है तो सर्वर निम्नलिखित कोड लौटाता है: 500 आंतरिक सर्वर त्रुटि: सर्वर में अप्रत्याशित समस्या के कारण अनुरोध पूरा नहीं हुआ। 502 खराब गेटवे: अपस्ट्रीम सर्वर से गलत प्रतिक्रिया के कारण अनुरोध पूरा नहीं हुआ। 503 सेवा अनुपलब्ध: रखरखाव, अधिभार या अन्य अस्थायी व्यवधानों के कारण सर्वर अनुरोध को संसाधित करने में असमर्थ था। आप सबसे आम HTTP कोड की सूची पा सकते हैं यहां 20. REST और GraphQL में क्या अंतर है? उत्तर: ग्राफ़क्यूएल एक क्वेरी भाषा है जो क्लाइंट को केवल वही डेटा क्वेरी करने की अनुमति देती है जिसकी उन्हें आवश्यकता होती है। ग्राफ़क्यूएल में, क्लाइंट उस डेटा की संरचना और प्रारूप को परिभाषित करता है जिसे वह प्राप्त करना चाहता है, और सर्वर उस अनुरोध के अनुसार उसे वापस कर देता है। मुख्य अंतर यह है कि REST में प्रत्येक संसाधन के लिए एक निश्चित अनुरोध और प्रतिक्रिया प्रारूप होता है, जबकि ग्राफ़क्यूएल क्लाइंट को अपना अनुरोध परिभाषित करने और केवल वही जानकारी प्राप्त करने की अनुमति देता है जिसकी उन्हें आवश्यकता होती है, जिससे यह उपयोग करने में अधिक कुशल और लचीला हो जाता है। 21. REST और SOAP में क्या अंतर है? उत्तर: REST और SOAP (सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल) API बनाने के दो तरीके हैं। उनके बीच 3 मुख्य अंतर हैं: SOAP सुरक्षित API बनाने के लिए एक सख्त प्रोटोकॉल है। REST एक प्रोटोकॉल नहीं है, बल्कि REST सिद्धांतों नामक दिशा-निर्देशों के एक सेट द्वारा निर्धारित एक वास्तुशिल्प शैली है। - REST API बनाना आसान है, हल्का है, और आम तौर पर SOAP API की तुलना में तेज़ है। SOAP API को REST API की तुलना में अधिक सुरक्षित माना जाता है, हालांकि REST API अभी भी सुरक्षा सुविधाओं को लागू कर सकते हैं, जिससे वे काफी सुरक्षित बन जाते हैं। - REST प्रतिक्रियाओं को कैश करने की अनुमति देता है, जबकि SOAP ऐसा नहीं करता है। SOAP डेटा को XML प्रारूप में एनकोड करता है। - REST आपको किसी भी प्रारूप में डेटा एनकोड करने की अनुमति देता है, हालांकि XML और JSON सबसे लोकप्रिय हैं। 22. REST और AJAX में क्या अंतर है? उत्तर: एसिंक्रोनस जावास्क्रिप्ट या AJAX वेब एप्लीकेशन में इस्तेमाल की जाने वाली वेब डेवलपमेंट तकनीकों का एक सेट है। इसके मूल में, AJAX एक वेब पेज को सर्वर से अनुरोध करने और पूरे पेज को अपडेट किए बिना पेज के इंटरफ़ेस को अपडेट करने की अनुमति देता है। AJAX क्लाइंट अपने अनुरोधों में REST API का उपयोग कर सकता है, लेकिन AJAX को केवल REST API के साथ काम करना ज़रूरी नहीं है। REST API किसी भी क्लाइंट के साथ संवाद कर सकते हैं, चाहे वह AJAX का उपयोग करता हो या नहीं। REST के विपरीत, जो संदेशों के आदान-प्रदान के लिए HTTP अनुरोधों और प्रतिक्रियाओं का उपयोग करता है, AJAX जावास्क्रिप्ट में निर्मित XMLHttpRequest ऑब्जेक्ट का उपयोग करके सर्वर को अपने अनुरोध भेजता है। सर्वर प्रतिक्रियाओं को पृष्ठ के जावास्क्रिप्ट कोड द्वारा निष्पादित किया जाता है ताकि इसकी सामग्री को बदला जा सके। 23. REST API विकास के लिए "अनुबंध पहले" दृष्टिकोण क्या है? उत्तर: REST API विकास के लिए अनुबंध प्रथम दृष्टिकोण एक कार्यप्रणाली है जिसमें वास्तविक विकास शुरू होने से पहले API विनिर्देश और अनुबंध बनाया और परिभाषित किया जाता है। यह अनुबंध एक महत्वपूर्ण दस्तावेज़ के रूप में कार्य करता है जो परिभाषित करता है कि क्लाइंट API के साथ कैसे बातचीत कर सकते हैं और विभिन्न अनुरोधों से क्या अपेक्षित परिणाम प्राप्त होंगे। 24. कॉन्ट्रैक्ट फर्स्ट के क्या लाभ हैं? उत्तर: अनुबंध प्रथम दृष्टिकोण के निम्नलिखित लाभ उल्लेखित किए जा सकते हैं: स्पष्ट API परिभाषा: API विनिर्देश और अनुबंध यह परिभाषित करते हैं कि API को ग्राहकों के साथ किस प्रकार बातचीत करनी चाहिए। जोखिम कम करें: ग्राहकों के साथ प्रारंभिक अनुबंध अनुमोदन गलतफहमी और API विकास अपेक्षाओं को पूरा करने में विफलता के जोखिम को कम करने में मदद करता है। बेहतर दस्तावेज़ीकरण: अनुबंध का पाठ अक्सर API के लिए दस्तावेज़ीकरण के रूप में कार्य करता है, जिससे इसका उपयोग और एकीकरण आसान हो जाता है। 25. REST API विकास के लिए कोड फर्स्ट दृष्टिकोण क्या है? उत्तर: REST API विकास के लिए कोड फर्स्ट दृष्टिकोण एक कार्यप्रणाली है जिसमें पहले API कार्यक्षमता विकसित की जाती है और फिर उस कार्यक्षमता के आधार पर एक API विनिर्देश स्वचालित रूप से उत्पन्न होता है। कोड फर्स्ट दृष्टिकोण की खासियत यह है कि डेवलपर्स API तर्क लिखने पर ध्यान केंद्रित करते हैं और ऐसे उपकरणों का उपयोग करते हैं जो उन्हें उस तर्क के आधार पर स्वचालित रूप से दस्तावेज़ीकरण और विनिर्देश बनाने की अनुमति देते हैं। सामान्य तौर पर, दोनों दृष्टिकोण, कोड फर्स्ट और कॉन्ट्रैक्ट फर्स्ट, को एक ही API विकास परियोजना के भीतर जोड़ा जा सकता है। इस मामले में, कोड फर्स्ट का उपयोग तेजी से प्रोटोटाइपिंग के लिए किया जाता है, उसके बाद कॉन्ट्रैक्ट फर्स्ट का उपयोग अनुबंध को औपचारिक रूप देने के लिए किया जाता है। मुझे आशा है कि यह लेख नौकरी के लिए साक्षात्कार की तैयारी करने या REST API के बारे में आपके ज्ञान को ताज़ा करने में आपके लिए उपयोगी होगा।
