बाकी एपीआई उदाहरण

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

एप्लिकेशन प्रोग्रामिंग इंटरफेस , या वेब एपीआई, सॉफ्टवेयर प्रोग्राम एक दूसरे के साथ संवाद करने के लिए उपयोग करते हैं। एपीआई दो कार्यक्रमों के बीच डेटा के आदान-प्रदान के लिए एक सुसंगत प्रोटोकॉल प्रदान करते हैं। वेब एपीआई की मदद से, आपका ऑनलाइन स्टोर डिलीवरी सॉफ्टवेयर, क्लाइंट एप्लिकेशन, भुगतान एप्लिकेशन और किसी भी अन्य आवश्यक कनेक्शन के साथ संचार कर सकता है।

एपीआई बनाने के कई तरीके हैं; हालाँकि, यदि आप अपनी सेवाओं में सॉफ़्टवेयर कनेक्शन जोड़ना चाहते हैं, तो एक अनूठी तकनीक है जिससे आपको परिचित होना चाहिए: REST APIs वेब सेवाएँ। इस लेख में, हम REST API के उदाहरणों पर चर्चा करेंगे कि REST API क्या है, REST API कैसे काम करता है, REST API का उपयोग किस लिए किया जाता है, इतिहास, इसके तत्व और बहुत कुछ।

एक आरईएसटी एपीआई वास्तव में क्या है?

प्रतिनिधि राज्य हस्तांतरण या आरईएसटी एपीआई वेब सेवाएं माइक्रोसर्विसेज ढांचे में घटकों को जोड़ने के लिए सबसे मानक अभ्यास हैं क्योंकि वे ऐप्स को शामिल करने के लिए एक बहुमुखी, पोर्टेबल तरीका प्रदान करते हैं। आरईएसटी एक लोकप्रिय एपीआई डिज़ाइन है जिसे हम एक मानकीकृत और अनुमानित तरीके से आंतरिक और बाहरी हितधारकों के साथ बातचीत करने के लिए नियोजित करते हैं।

वेब एप्लिकेशन के उपयोगकर्ता अक्सर एक दूसरे के साथ संवाद करने के लिए आरईएसटी एपीआई वेब सेवाओं को नियोजित करते हैं। उदाहरण के लिए, सोशल मीडिया प्रोग्राम में खाता विवरण प्राप्त करना और उसकी समीक्षा करना। REST API ब्राउज़र को वेब के सिंटैक्स के रूप में देखा जा सकता है। क्लाउड का उपयोग बढ़ने पर ऑनलाइन ग्राहक डिजिटल संचालन तक पहुंच प्रदान करने और प्रबंधित करने के लिए वेब एपीआई का उपयोग करते हैं।

वेब एपीआई को डिजाइन करना जो ग्राहकों को एक बिखरे हुए संदर्भ में गतिशील रूप से डिजिटल वेब सेवाओं से जुड़ने, प्रशासित करने और संलग्न करने में सक्षम बनाता है, एक समझदार निर्णय है। Google, eBay, Facebook, Amazon और Twitter जैसी वेबसाइटें RESTful वेब सेवाओं का उपयोग करती हैं। क्लाइंट एप्लिकेशन अब इन वेब सेवाओं तक पहुंचने के लिए आरईएसटी का उपयोग कर सकते हैं।

अन्य संबंधित तकनीकों पर REST तकनीक का समर्थन किया जाता है। ऐसा इसलिए है क्योंकि आरईएसटी वेब सेवाएं कम बैंडविड्थ की खपत करती हैं, जो उन्हें प्रभावी ऑनलाइन गतिविधि के लिए आदर्श बनाती हैं। जावास्क्रिप्ट या पायथन जैसी प्रोग्रामिंग भाषाओं का उपयोग करके रेस्टफुल वेब सेवाओं को भी विकसित किया जा सकता है।

आरईएसटी एपीआई कैसे काम करते हैं?

यह जानने के लिए कि REST API कैसे काम करता है, हमें कुछ प्रमुख शब्दों को परिभाषित करना चाहिए:

ग्राहक

एक एपीआई उपयोगकर्ता को क्लाइंट के रूप में जाना जाता है। क्लाइंट डेटा प्राप्त करने या प्रोग्राम में संशोधन लागू करने के लिए वेब एपीआई को प्रश्न भेजता है। आपका इंटरनेट ब्राउज़र क्लाइंट है; यह पृष्ठ सामग्री प्राप्त करने के लिए विभिन्न वेब एपीआई के साथ संचार करता है। आपका कंप्यूटर आवश्यक जानकारी प्राप्त करता है, जिसे बाद में डिस्प्ले पर दिखाया जाता है।

सबसे लोकप्रिय HTTP विधियाँ निम्नलिखित हैं:

• अनुरोधित डेटा या अनुरोधित संसाधनों को वापस करने के लिए GET अनुरोध का उपयोग करें।
• नया संसाधन बनाने के लिए POST अनुरोध का उपयोग करें
• मौजूदा संसाधन में बदलाव करने या उसे अपडेट करने के लिए PUT निर्देश का उपयोग करें
• संसाधन से छुटकारा पाने के लिए DELETE कमांड का उपयोग करें।

उदाहरण के लिए, यूट्यूब के एपीआई के लिए एक HTTP अनुरोध किसी विशेष वीडियो या पोस्ट के लिए जीईटी अनुरोध संसाधन या एक नई तस्वीर प्रकाशित करने के लिए एक पोस्ट अनुरोध हो सकता है। आप नई पोस्ट प्रकाशित करने के लिए POST अनुरोध विधि का उपयोग कर सकते हैं। इसके अनुरूप, एक ग्राहक वेब सेवा प्लेटफॉर्म जो एक ऑटो-अटेंडेंट कार्यान्वयन के साथ एकीकृत होता है, कस्टम हैलो को अपडेट करने या समाप्त करने के लिए PUT निर्देश को नियोजित कर सकता है।

अनुरोध प्राप्त करें

• GET अनुरोध कैशिंग संभव है। ब्राउज़र के इतिहास में GET अनुरोध शामिल हैं।
• GET अनुरोधों को बुकमार्क करना संभव है।
• महत्वपूर्ण सामग्री के साथ काम करते समय कभी भी GET अनुरोधों का उपयोग न करें।
• GET अनुरोधों की लंबाई सीमाएँ हैं।
• केवल डेटा क्वेरी GET अनुरोधों के माध्यम से की जाती हैं

Try AppMaster no-code today!

Platform can build any web, mobile or backend application 10x faster and 3x cheaper

Start Free

पोस्ट विधि

POST अनुरोध संसाधनों को जोड़ने या अद्यतन करने के लिए सर्वर को जानकारी भेजने के लिए एक पोस्ट विधि है। HTTP अनुरोध के अनुरोध निकाय में वह डेटा होता है जो सर्वर साइड पर प्रकाशित होता है:

• POST अनुरोध पोस्ट विधि कभी भी कैश में नहीं जाती है।
• POST अनुरोध ब्राउज़र के इतिहास में संग्रहीत नहीं होते हैं।
• पोस्ट अनुरोध बुकमार्क करने योग्य नहीं हैं

प्रतिक्रिया निकाय

रिस्पांस बॉडी RESTful API के महत्वपूर्ण तत्वों में से एक है। अनुरोधित डेटा प्रतिक्रिया निकाय में शामिल है। प्रतिक्रिया निकाय में आउटपुट और आउटपुट लॉजिक पोर्ट से संबंधित डेटा शामिल हो सकता है।

संसाधन

कोई भी डेटा जो वेब एपीआई उपयोगकर्ता को दे सकता है वह एक संसाधन है। उदाहरण के लिए, किसी व्यक्ति, पेज, चित्र या टिप्पणी को Facebook API में संसाधन माना जा सकता है। संसाधन पहचानकर्ता प्रत्येक संसाधन को दिया गया एक विशेष शब्द है।

वेब सर्वर

ग्राहक अनुरोध निकाय को स्वीकार करने वाला प्रोग्राम एक वेब सर्वर का उपयोग करता है, जिसमें उपभोक्ता द्वारा मांगे जाने वाले संसाधन होते हैं। सर्वर एक एपीआई के माध्यम से ग्राहकों के साथ संचार कर सकता है बिना ग्राहकों को अपने डेटाबेस में रखी गई जानकारी तक तत्काल पहुंच प्रदान करता है। जब कोई उपयोगकर्ता अनुरोध निकाय सबमिट करने के लिए रीस्टफुल वेब सेवाओं तक पहुंचता है, तो सर्वर ब्राउज़र को संसाधन की स्थिति का सामान्यीकृत चित्रण भेजता है।

यह दर्शाता है कि सर्वर किसी तरह क्लाइंट को सटीक संसाधन प्रस्तुत नहीं करता है, बल्कि उसकी स्थिति को दर्शाता है, अर्थात, एक विशिष्ट टाइमस्टैम्प पर संसाधन की स्थिति। बोधगम्यता में सहायता के लिए, प्रतिक्रियाएँ हल्के प्रारूप में दी जाती हैं।

JSON (जावास्क्रिप्ट ऑब्जेक्ट नोटेशन) का व्यापक रूप से उपयोग किया जाता है क्योंकि यह लोगों और मशीनों दोनों द्वारा सुपाठ्य है और वेब एक्सेसिबिलिटी को बढ़ावा देने में मदद करता है। JSON का उपयोग मुख्य रूप से वेब एप्लिकेशन और क्लाइंट एप्लिकेशन में अनुरोध निकाय भेजने के लिए किया जाता है। यह विभिन्न प्रकार की कोडिंग के साथ संगत रूप है। JSON के अलावा अन्य API डेटा स्वरूपों में XML , YAML, CSV, HTML और सादा पाठ शामिल हैं। एपीआई के उपयोगकर्ता कस्टम मीडिया प्रकारों का उपयोग करके अपनी इच्छानुसार किसी भी डेटा प्रारूप का चयन कर सकते हैं।

आरईएसटी एपीआई का इतिहास

कई प्रोग्रामर को एपीआई को शामिल करने के लिए आरईएसटी से पहले एसओएपी के साथ काम करना पड़ा। SOAP का निर्माण, उपयोग और डिबगिंग बेहद कठिन कार्य थे। शुक्र है, REST को रॉय फील्डिंग के निर्देशन में प्रोग्रामर्स की एक टीम द्वारा विकसित किया गया था, जो हमेशा के लिए API वातावरण को बदल रहा था।

यहाँ समय के साथ REST API के विकास का कालक्रम है:

REST . से पहले

प्रोग्रामर्स ने मैन्युअल रूप से एक XML फ़ाइल लिखी जिसमें SOAP का उपयोग करके वेब API को कनेक्ट करने के लिए सामग्री के अंदर रिमोट प्रोसीजर कॉल (RPC) शामिल है। उसके बाद, डिजाइनर अपने SOAP पैकेज को निर्दिष्ट समापन बिंदु पर पोस्ट करेंगे।

वर्ष 2000 . में

रॉय फील्डिंग के नेतृत्व में प्रोग्रामर्स की एक टीम ने किसी भी सर्वर को किसी अन्य सर्वर के साथ संचार करने में सक्षम बनाने के लिए एक ढांचा विकसित करना चुना। उन्होंने आरईएसटी एपीआई के लिए प्रतिबंध लगाए। चूंकि ये दिशानिर्देश सार्वभौमिक हैं, इसलिए सॉफ्टवेयर विकसित करना आसान है।

वर्ष 2002 . में

ईबे ने 2002 में अपना रीस्टफुल एपीआई विकसित किया, जिसने अपने बाज़ार को किसी भी वेबसाइट के लिए खोल दिया जो इससे लाभान्वित हो सकती है। इस वजह से, ई-कॉमर्स का एक और टाइटन, अमेज़न, इसमें दिलचस्पी लेने लगा और 2002 में, अपना RESTful API जारी किया।

वर्ष 2004-2006 में

फ़्लिकर की रीस्टफुल वेब सेवाओं को 2004 में जारी किया गया था, जिससे लेखकों को अपनी वेबसाइटों और सोशल मीडिया पोस्टों में जल्दी से तस्वीरें जोड़ने की अनुमति मिली। जब ट्विटर और फेसबुक ने देखा कि बड़ी संख्या में प्रोग्रामर वेबसाइटों को स्कैन कर रहे हैं और "फ्रेंकस्टीन" एपीआई बना रहे हैं, तो दोनों ने लगभग दो साल बाद अपने एपीआई का खुलासा किया।

वर्ष 2006-वर्तमान में

RESTful वेब सेवाओं को अब प्रोग्रामर द्वारा व्यापक रूप से स्वीकार किया जाता है, जो इन RESTful वेब सेवाओं का उपयोग अपने ऐप्स और साइटों के प्रदर्शन को बेहतर बनाने के लिए करते हैं। AppMaster सहयोग की सुविधा देता है और एपीआई का निर्माण आसान बनाता है, जिससे आप इसे और अधिक तेज़ी से कर सकते हैं।

Try AppMaster no-code today!

Platform can build any web, mobile or backend application 10x faster and 3x cheaper

Start Free

आरईएसटी एपीआई किसके लिए उपयोग किए जाते हैं?

RESTful वेब सेवाओं के मुख्य लाभों में से एक यह है कि यह बहुत अधिक लचीलापन प्रदान करता है, जिससे आप इस RESTful API का अधिक प्रभावी ढंग से उपयोग कर सकते हैं। नीचे कुछ आरईएसटी एपीआई उदाहरण दिए गए हैं कि आरईएसटी एपीआई का क्या उपयोग किया जाता है।

क्लाउड-आधारित अनुप्रयोग

इसकी कॉल की स्टेटलेसनेस के कारण, क्लाउड एप्लिकेशन में REST API फायदेमंद होते हैं। अगर कुछ गलत हो जाता है तो क्षमता की आवश्यकता को पूरा करने के लिए स्टेटलेस मॉड्यूल आसानी से पुनर्स्थापित और विकसित हो सकते हैं। स्थानीय और इंटरनेट-आधारित घटकों को मिलाने वाला एक सॉफ्टवेयर प्रोग्राम एक क्लाउड एप्लिकेशन है। यह प्रतिमान निर्देशों को निष्पादित करने के लिए एक वेब ब्राउज़र और चल रही इंटरनेट वेब सेवाओं द्वारा एक्सेस किए गए दूरस्थ सर्वर का उपयोग करता है।

क्लाउड एप्लिकेशन होस्ट का पारंपरिक स्थान एक तृतीय-पक्ष क्लाउड कंप्यूटिंग नेटवर्क ऑपरेटर द्वारा चलाया जाने वाला एक दूरस्थ कंप्यूटर सिस्टम है। मेल, दस्तावेज़ साझाकरण और भंडारण, ऑर्डर इनपुट, इन्वेंट्री नियंत्रण, माइक्रोसॉफ्ट वर्ड, ग्राहक संबंध प्रबंधन ( सीआरएम ), सूचना एकत्र करना, और वित्त और लेखांकन क्लाउड-आधारित अनुप्रयोगों के साथ किए गए कार्यों के उदाहरण हैं।

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

क्लाउड एप्लिकेशन का एक प्रमुख उदाहरण Google डॉक्स या ऑफिस 365 है। Google डॉक्स या ऑफिस 365 के लिए आपको केवल एक कंप्यूटर की आवश्यकता होती है जो सर्च इंजन और इंटरनेट वेब सेवाएं चला सकता है। कंप्यूटर नेटवर्क सूचना भंडारण सहित यूजर इंटरफेस और संचालन प्रदान करते हैं। क्लाउड एप्लिकेशन होस्ट का उपयोग करके आपकी कंपनी द्वारा कई अलग-अलग क्लाउड ऐप्स होस्ट किए जा सकते हैं।

क्लाउड सेवाएं

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

अंतिम उपयोगकर्ता क्लाउड वेब सेवाओं द्वारा प्रदान की जाने वाली क्लाइंट एप्लिकेशन या वेब सेवाओं तक पहुंच सकते हैं, जैसे कि कम्प्यूटेशनल इन्फ्रास्ट्रक्चर, स्टोरेज सिस्टम या ट्रैकिंग सिस्टम, रेस्टफुल वेब सेवाओं जैसी क्लाउड सेवा का उपयोग करके। एपीआई एक एप्लिकेशन की क्षमताओं और संचालन और उन्हें पूरा करने के लिए आवश्यक विशिष्टताओं की रूपरेखा तैयार करते हैं। क्लाइंट की गोपनीयता और सुरक्षा बनाए रखने के लिए, एपीआई अक्सर REST या सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल (SOAP) इंटरऑपरेबिलिटी और OAuth 2.0 जैसे अनुमति तंत्र पर निर्भर करते हैं।

विभिन्न प्रकार की वेब सेवाओं को "क्लाउड सेवाओं" के रूप में संदर्भित किया जाता है और अनुरोध पर व्यवसायों और उपभोक्ताओं को ऑनलाइन उपलब्ध कराया जाता है। इन वेब सेवाओं को हार्डवेयर या बुनियादी ढांचे की आवश्यकता के बिना टूल और ऐप्स तक त्वरित, सस्ती पहुंच प्रदान करने के लिए बनाया गया है। अधिकांश कर्मचारी ईमेल से लेकर दस्तावेज़ सहयोग तक हर चीज़ के लिए क्लाउड वेब सेवाओं का उपयोग करते हैं।

वेब उपयोग

ये वेब एपीआई उपयोगकर्ता वेब प्रोजेक्ट, आईफोन ऐप , आईओटी डिवाइस या विंडोज मोबाइल से प्राप्त किए जा सकते हैं क्योंकि आरईएसटी क्लाइंट-साइड कार्यक्षमता पर निर्भर नहीं है। आप किसी विशिष्ट क्लाइंट-साइड फ्रेमवर्क तक सीमित हुए बिना अपने व्यवसाय के लिए आर्किटेक्चर बना सकते हैं।

एक आरईएसटी एपीआई उदाहरण

आइए एक आरईएसटी एपीआई उदाहरण पर चर्चा करें। ओपन ट्रिविया डेटाबेस को एक मनमानी खुफिया जांच पूछने के लिए नीचे दिए गए लिंक पर क्लिक करें: ऐसी रीस्टफुल वेब सेवाओं का उपयोग सार्वजनिक वेब एपीआई प्रदान करने के लिए किया गया था। आपका कंप्यूटर एक अकेला प्रश्नोत्तरी प्रश्न और उसके जवाब JSON प्रारूप में प्रदर्शित करेगा।

Try AppMaster no-code today!

Platform can build any web, mobile or backend application 10x faster and 3x cheaper

Start Free

url जैसे किसी HTTP ब्राउज़र का उपयोग करके, आप निम्न क्वेरी जारी कर सकते हैं और प्रतिक्रिया निकाय में प्रतिक्रिया प्राप्त कर सकते हैं: https://opentdb.com/api.php?amount=1&category=18

वेब सेवा की XML फ़ाइल के रिस्पांस बॉडी में कर्मचारी की सभी जानकारी होगी।

सभी व्यापक रूप से उपयोग की जाने वाली प्रोग्रामिंग बोलियों और डेवलपर टूल में HTTP क्लाइंट लाइब्रेरी हैं, जैसे कि जावास्क्रिप्ट, Node.js, और डेनो में पुनर्प्राप्त करें और PHP में फ़ाइल प्राप्त करें ()। JSON उत्तर को पढ़ा और उपयोग किया जा सकता है क्योंकि यह HTML या किसी अन्य शैली में प्रदर्शित होने से पहले मशीन द्वारा पठनीय है।

बाकी और बाकी एपीआई

समय के साथ, कई डेटा ट्रांसमिशन विधियों का विकास हुआ है। आपको CORBA, SOAP, या XML-RPC जैसे विकल्प मिले होंगे। सर्वाधिक विकसित कड़े संदेश दिशानिर्देश। रॉय फील्डिंग ने पहली बार 2000 में REST को रेखांकित किया, जो दूसरों की तुलना में बहुत अधिक सीधा है।

यह एक मानक के बजाय RESTful वेब सेवाओं के लिए सुझावों और सीमाओं का एक संग्रह है। इनमें निम्नलिखित वास्तु बाधाएं शामिल हैं:

क्लाइंट-सर्वर विभाजन

क्लाइंट और वेब सर्वर केवल REST आर्किटेक्चर के तहत एक दिशा में संचार कर सकते हैं: क्लाइंट डोमेन नियंत्रक का अनुरोध करता है, और नियंत्रक या सर्वर अनुरोध का जवाब देता है। वेब सर्वर अनुरोध सबमिट करने में असमर्थ हैं, और ग्राहक प्रतिक्रिया करने में असमर्थ हैं; उपभोक्ता सभी कनेक्शन शुरू करता है।

रीस्टफुल वेब सेवाएं ग्राहकों और सर्वरों के बीच बातचीत को आसान बनाकर अलग-थलग रखती हैं। क्लाइंट कंप्यूटर किसी अन्य होस्टिंग को प्रभावित करने के डर के बिना विकसित हो सकते हैं, और सर्वर सामग्री को ग्राहकों को अनजाने में प्रभावित किए बिना बदला जा सकता है।

यूनिफ़ॉर्म इंटरफ़ेस

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

सामान्यीकृत बातचीत वाले अनुप्रयोगों के बीच अनुरोधों और प्रतिक्रियाओं का अनुवाद करना ही संभव होगा। मामूली अंतरों से जानकारी खो जाएगी और जब वेब एपीआई अपनी अनुरोध प्रक्रियाओं को संशोधित करेंगे तो समाधानों को अपनी अनुरोध प्रक्रियाओं को अपग्रेड करना होगा। एक सुसंगत इंटरफ़ेस इस संभावना को समाप्त करता है।

https://www.googleapis.com/youtube/v3/channels?part=contentDetails तक पहुंच प्राप्त करें

सभी आरईएसटी क्लाइंट अनुप्रयोगों की तरह, इस प्रस्ताव में डेटा के दो टुकड़े शामिल हैं। HTTP तकनीक GET है। यह उस क्रिया का वर्णन करता है जो ग्राहक संसाधनों पर लेना चाहता है। एक उपयोगकर्ता चार बुनियादी HTTP तरीके बना सकता है:

HTTP, या हाइपर-टेक्स्ट ट्रांसफर प्रोटोकॉल, अधिकांश REST API के लिए सार्वभौमिक भाषा है। HTTP को REST को ध्यान में रखकर नहीं बनाया गया था। इसके अतिरिक्त, आरईएसटी ने इस डेटा ट्रांसमिशन को आरईएसटी-जागरूक ऐप्स के मानदंड के रूप में स्वीकार किया। REST API के साथ HTTP का उपयोग करने के लिए, क्लाइंट एक ऐसे प्रारूप में एक अनुरोध सबमिट करता है जिससे आप परिचित हो सकते हैं। उदाहरण के लिए, यूट्यूब एपीआई के लिए एक वीडियो सिग्नल याचिका इस तरह दिखती है:

• संसाधन प्राप्त करने के लिए GET कमांड का उपयोग करें।
• नया संसाधन बनाने के लिए POST कमांड का उपयोग करें
• मौजूदा संसाधन में बदलाव करने या उसे अपडेट करने के लिए PUT निर्देश का उपयोग करें
• किसी संसाधन से छुटकारा पाने के लिए DELETE अनुरोध का उपयोग करें।

HTTP विधियाँ एक विशिष्ट संसाधन के संबंध में की जाने वाली इच्छित कार्रवाई को निर्दिष्ट करती हैं। HTTP विधियों को HTTB क्रिया के रूप में भी जाना जाता है।

यूआरएल HTTP है

यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर या यूआरआई, जो लक्षित संसाधन की पहचान करता है, यूआरएल में निहित है। इस परिदृश्य में URL भी एक समापन बिंदु है क्योंकि यह वह जगह है जहाँ RESTful API सेवा उपयोगकर्ता के संपर्क में आता है।

क्वेरी स्ट्रिंग: URL में एक क्वेरी स्ट्रिंग शामिल है। क्वेरी स्ट्रिंग का उपयोग पैरामीटर को परिभाषित करने के लिए किया जाता है, जो मान दिए जाते हैं।

याचिका प्राप्त करने और सत्यापित करने के बाद, वेब सर्वर लक्षित संसाधन पर डेटा वापस कर देता है। आमतौर पर, डेटा JSON (जावास्क्रिप्ट ऑब्जेक्ट नोटेशन) नामक संरचना में लौटाया जाता है। JSON एक पोर्टेबल प्रारूप में संसाधन के सभी घटकों को प्रस्तुत करता है जिसे मनुष्य आसानी से पढ़ सकते हैं।

Try AppMaster no-code today!

Platform can build any web, mobile or backend application 10x faster and 3x cheaper

Start Free

समान इंटरफ़ेस के सिद्धांत

समान इंटरफ़ेस को निम्नलिखित मापदंडों का पालन करना चाहिए:

• HATEOAS: हाइपरमीडिया अनुप्रयोग स्थिति के इंजन के रूप में

  हाइपरमीडिया रीस्टफुल वेब सेवाओं के पीछे का इंजन है। यह इंगित करता है कि हाइपरमीडिया वह सब है जो ग्राहक प्रदाता के उत्तर को पहचानने के लिए समझना चाहता है।

• क्लाइंट को केवल क्लाइंट एप्लिकेशन का पहला यूआरआई प्रदान किया जाना चाहिए। क्लाइंट एप्लिकेशन को हाइपरलिंक्स का उपयोग करके अन्य सभी सामग्रियों और गतिविधियों को लगातार चलाना चाहिए।
• RESTful वेब सेवाओं को इनपुट क्वेरी भाषा (IDL) की आवश्यकता नहीं होती है, जो अन्य APIs से भिन्न होती है

एक मीडिया प्रकार एक प्रतिनिधित्व के डेटा प्रारूप के लिए एक नाम है। मीडिया प्रकार एक परिभाषा की पहचान करता है जो यह बताता है कि चित्रण को कैसे व्यवहार किया जाना चाहिए। आरईएसटी का उपयोग करने वाला एक वेब एपीआई हाइपरटेक्स्ट जैसा लगता है। प्रत्येक डेटा आइटम जिसे संबोधित किया जा सकता है, या तो सीधे (जैसे लिंक और पहचान गुणों के माध्यम से) या परोक्ष रूप से (उदाहरण के लिए, मीडिया प्रकार विवरण संरचना से प्राप्त) एक स्थान रखता है।

• स्व-वर्णनात्मक संदेश

  क्लाइंट साइड और सर्वर साइड के बीच प्रत्येक संचार को संचार निष्पादित करने के लिए पर्याप्त डेटा प्रदान करना चाहिए। तदनुसार, क्लाइंट की ओर से सर्वर की ओर से अनुरोध को उस संसाधन को निर्दिष्ट करने की आवश्यकता है जिसे वह अपने विशिष्ट लक्ष्यों के साथ एक्सेस करने का प्रयास कर रहा है।
  
  

  इसके अतिरिक्त, संसाधन चित्रण स्व-वर्णनात्मक होना चाहिए; उपयोगकर्ता को यह जानने की आवश्यकता नहीं है कि संसाधन एक व्यक्ति है या उपकरण का एक टुकड़ा है। इसके बजाय, उसे मदद से जुड़े मीडिया प्रकार का अनुसरण करना चाहिए।

  
  इसलिए, निर्विवाद रूप से, हम कई अद्वितीय मीडिया प्रकार विकसित करेंगे, अक्सर प्रति संसाधन एक मीडिया प्रकार। मीडिया का हर रूप एक मानक उत्पादन प्रतिमान निर्दिष्ट करता है। उदाहरण के लिए, HTML परिभाषित करता है कि हाइपरटेक्स्ट कैसे दिखाया जाता है और ब्राउज़र प्रत्येक घटक को कैसे संभालता है।
  
  

• संसाधनों की पहचान

  ग्राहक और सर्वर के बीच पिछले संचार में संदर्भित संसाधनों को चित्रणों का उपयोग करके पहचानने योग्य होना चाहिए। इसके लिए अनुमत यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर (URI) सिस्टम से चिपके रहना। दूसरे शब्दों में, सर्वर से ग्राहक तक संचार में दस्तावेज़ का एक HTML संस्करण और सर्वर के भंडारण से वास्तविक फ़ाइल के बजाय कुछ जानकारी शामिल हो सकती है।
  
  

  उपभोक्ता HTML संस्करण को आसानी से समझ सकता है क्योंकि यह URI पैटर्न का अनुसरण करता है। ग्राहक को सर्वर को इस बात का चित्रण देकर संसाधनों को संशोधित करना चाहिए कि संसाधन अंततः कैसे प्रकट होना चाहिए। यह उपयोगकर्ता को संसाधनों को बनाने, पुनर्प्राप्त करने, संशोधित करने और निकालने में सक्षम बनाता है। यदि ग्राहक के पास डेटा बदलने के लिए आवश्यक प्राधिकरण है, तो सर्वर को क्वेरी को पूरा करना चाहिए।

राज्यविहीन

एक RESTful API के साथ, सभी क्लाइंट अनुरोध क्षणिक होने चाहिए। नतीजतन, प्रत्येक क्वेरी और प्रतिक्रिया निकाय में अनुबंध समाप्त करने के लिए आवश्यक सभी डेटा शामिल होते हैं, जिससे प्रत्येक कनेक्शन स्वायत्त होता है। सर्वर पिछले HTTP अनुरोधों का ट्रैक नहीं रखता है; यह क्लाइंट द्वारा बनाई गई हर एक को पूरी तरह से नई क्वेरी के रूप में मानता है।

चूंकि सर्वर को ऐतिहासिक डेटा प्राप्त करने के लिए कोई अतिरिक्त कार्य करने की आवश्यकता नहीं है, स्टेटलेस ट्रांसपोर्ट सर्वर के लिए आवश्यक भंडारण की मात्रा को काफी कम कर देता है और इस संभावना को बढ़ाता है कि प्रतिक्रिया स्वीकार्य होगी। यह इन इंटरैक्शन की मापनीयता की गारंटी देता है: प्रोग्रामर को अधिक स्टोरेज का उपयोग करने या सर्वर पर कर लगाने के बारे में चिंतित होने की आवश्यकता नहीं है जब उनका सॉफ़्टवेयर विस्तारित होता है और HTTP अनुरोध करता है।

बहुस्तरीय

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

इस अवधारणा के अनुसार, उपयोगकर्ता और लक्ष्य सर्वर के बीच भेजे गए संदेशों को समान रूप से संरचित और नियंत्रित किया जाना चाहिए, चाहे बीच में मौजूद कोई भी परत हो। ग्राहक इंटरैक्शन के साथ अतिरिक्त परतें ठीक होनी चाहिए। इस नियम का पालन करने वाले प्रोग्रामर मौलिक अनुरोध-प्रतिक्रिया प्रक्रिया को प्रभावित किए बिना सर्वर सिस्टम को बदल सकते हैं।

Try AppMaster no-code today!

Platform can build any web, mobile or backend application 10x faster and 3x cheaper

Start Free

संचित करने योग्य

कैशिंग तब होती है जब कोई ग्राहक किसी वेबसाइट को ब्राउज़ करता है जब ग्राहक की मशीन पर सामग्री सहेजी जाती है। जब कोई उपयोगकर्ता बाद में उस साइट पर जाता है तो सर्वर से फिर से डाउनलोड होने के बजाय कैश्ड सामग्री को आंतरिक मेमोरी से तेजी से लोड किया जाता है। अधिकांश बड़ी साइटें सर्वर स्थान और बैंडविड्थ का संरक्षण करते हुए पृष्ठ लोड को कम करने के लिए कैशिंग का उपयोग करती हैं।

आरईएसटी एपीआई विकसित करते समय डेटा कैशिंग पर विचार किया जाता है। एक सर्वर ग्राहक को जो प्रतिक्रिया देता है, उसमें यह बताना चाहिए कि दिए गए संसाधन को कितनी दूर तक संग्रहीत किया जा सकता है।

इन डिमांड कोड

अंतिम आरईएसटी सिद्धांत अनावश्यक है। यदि अनुरोध किया जाता है, तो एपीआई की प्रतिक्रिया में क्लाइंट के उपयोग के लिए सॉफ़्टवेयर कोड शामिल हो सकता है। इस वजह से, ग्राहक क्लाइंट एप्लिकेशन या प्रोग्राम को उसके बैकएंड में निष्पादित कर सकता है।

एक API को एक RESTful API माना जाता है यदि वह दिशानिर्देशों के इस सेट का अनुपालन करता है। हालाँकि, ये दिशानिर्देश प्रोग्रामर को अपने RESTful API की सुविधाओं को संशोधित करने की बहुत स्वतंत्रता देते हैं। REST API सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल, एक अन्य लोकप्रिय वेब API तकनीक से भिन्न है, जिसमें वे अधिक लचीले (SOAP) हैं।

समापन बिंदु सहमति

इन समापन बिंदुओं को ध्यान में रखें:

• /उपयोगकर्ता/123\s
• /उपयोगकर्ता/आईडी/123\s
• /उपयोगकर्ता/123\s/उपयोगकर्ता/आईडी/123\s
• /उपयोगकर्ता/?आईडी=123

क्लाइंट 123 के लिए डेटा पुनर्प्राप्त करने के लिए सभी वैध तरीके हैं। जब अधिक जटिल प्रक्रियाएं होती हैं, तो संभावनाओं की संख्या बढ़ जाती है। उदाहरण के लिए, प्रविष्टि 51 से शुरू होने वाले उल्टे क्रम में, अंतिम नाम वाले 10 लोगों को प्रदर्शित करें जो "ए" से शुरू होते हैं और कंपनी के लिए काम करते हैं।

अंत में, यह परवाह नहीं करता कि आप URL की संरचना कैसे करते हैं; आपके RESTful API में एकरूपता मायने रखती है। कई प्रोग्रामर के साथ विशाल सॉफ्टवेयर सिस्टम पर, यह आसान नहीं हो सकता। रीस्टफुल एपीआई संशोधन अपरिहार्य हैं, लेकिन एंडपॉइंट यूआरएल को कभी भी अस्वीकार नहीं किया जाना चाहिए क्योंकि ऐसा करने से उन ऐप्स को काम करना बंद हो जाएगा जो उन पर भरोसा करते हैं।

रेस्ट एपीआई वर्जनिंग

असंगतताओं को रोकने के लिए एपीआई का संस्करण बनाना एक आम बात है। उदाहरण के तौर पर, /2.0/user/123 /user/123 को प्रतिस्थापित करता है। पुराने और नए समापन बिंदु दोनों कार्य करना जारी रख सकते हैं। नतीजतन, यह पिछले महत्वपूर्ण एपीआई को बनाए रखने की आवश्यकता को मजबूर करता है। पिछले संस्करणों को अंततः सेवानिवृत्त किया जा सकता है, लेकिन प्रक्रिया को सावधानीपूर्वक सोचा जाना चाहिए।

बाकी एपीआई प्रमाणीकरण

कोई भी उपकरण पूछताछ एपीआई का उपयोग करके प्राधिकरण के बिना एक क्विप डाउनलोड कर सकता है। एपीआई जो निजी जानकारी पढ़ते हैं या प्रश्नों को संपादित करने और हटाने की अनुमति देते हैं, वे इसका समर्थन नहीं करते हैं। क्लाइंट-साइड प्रोग्राम उसी डोमेन के भीतर होते हैं जिसमें RESTful वेब सेवाएँ भेजी जाती हैं और HTTP अनुरोधों की तरह ही कुकीज़ प्राप्त करती हैं। (कृपया ध्यान दें कि विशेषाधिकार पुनः आरंभ करने का विकल्प Fetch() के लिए पहले की साइटों में निर्दिष्ट किया जाना चाहिए।) एक एपीआई क्वेरी को यह पुष्टि करने के लिए सत्यापित किया जा सकता है कि उपयोगकर्ता साइन इन है और उसके पास आवश्यक अनुमतियां हैं।

HTTP मूल प्रमाणीकरण : तृतीय-पक्ष कार्यक्रमों को विभिन्न अनुमोदन समाधानों का उपयोग करना चाहिए। प्रमाणीकरण के कुछ लोकप्रिय तरीके इसके लिए प्राथमिक सत्यापन हैं:

• एचटीटीपी। एक बेस 64-एन्कोडेड उपयोगकर्ता नाम: पासवर्ड स्ट्रिंग एक HTTP अनुमोदन शीर्षलेख के भाग के रूप में क्वेरी फ़ील्ड में दी गई है।
• API कुंजियाँ: एक RESTful API कुंजी प्रदान करके जिसमें विशेष अनुमतियाँ हो सकती हैं या एक साइट तक सीमित हो सकती हैं, तृतीय-पक्ष अनुप्रयोगों के लिए एक API उपलब्ध कराया जाता है। प्रत्येक संदेश में या तो क्वेरी स्ट्रिंग पर या HTTP शीर्षलेख में कुंजी होती है। (क्वेरी स्ट्रिंग URL का एक घटक है)।
• OAuth: कोई भी अनुरोध करने से पहले, एक ग्राहक आईडी और शायद एक ग्राहक रहस्य एक OAuth सर्वर को एक क्रेडेंशियल प्राप्त करने के लिए भेजा जाता है। इसकी समाप्ति तक, OAuth पहचान तब प्रत्येक API अनुरोध के साथ प्रेषित की जाती है।
• JSON (JWT) में इंटरनेट टोकन: क्वेरी हेडर और प्रतिक्रिया हेडर सुरक्षित रूप से डिजिटल रूप से हस्ताक्षरित उपयोगकर्ता क्रेडेंशियल्स को व्यक्त करते हैं। JWTs सर्वर को एक्सेस विशेषाधिकारों को एन्क्रिप्ट करने में सक्षम बनाता है, डेटाबेस को क्वेरी करने या किसी अन्य प्रमाणीकरण तंत्र का उपयोग करने की आवश्यकता को समाप्त करता है।

Try AppMaster no-code today!

Platform can build any web, mobile or backend application 10x faster and 3x cheaper

Start Free

उपयोग परिदृश्य प्रभावित करेगा कि एपीआई कैसे प्रमाणित होता है:

• कभी-कभी, किसी तृतीय-पक्ष प्रोग्राम को समान विशेषाधिकारों और अधिकारों के साथ किसी अन्य लॉग-इन क्लाइंट की तरह नियंत्रित किया जाता है। उदाहरण के लिए, एक नक्शा एपीआई दो स्थानों के बीच निर्देशों के साथ एक अनुरोध कार्यक्रम प्रदान कर सकता है। यह सत्यापित करना चाहिए कि कार्यक्रम एक वैध उपयोगकर्ता है, लेकिन इसे क्लाइंट के क्रेडेंशियल्स को सत्यापित करने की आवश्यकता नहीं है।
• अन्य स्थितियों में, तृतीय-पक्ष प्रोग्राम किसी विशिष्ट उपयोगकर्ता से व्यक्तिगत जानकारी मांगता है, जैसे कि मेल सामग्री। आरईएसटी एपीआई को क्लाइंट और उनकी अनुमतियों को पहचानना होगा, लेकिन उन्हें कॉलिंग प्रोग्राम से चिंतित होने की आवश्यकता नहीं है।

बाकी एपीआई सुरक्षा

RESTful वेब सेवाएँ आपके सॉफ़्टवेयर के साथ सहभागिता करने और उसे प्रभावित करने का एक और तरीका जोड़ती हैं। भले ही आपका होस्ट एक उन्नत हैकिंग उद्देश्य न हो, एक दुर्व्यवहार करने वाला उपयोगकर्ता प्रति सेकंड सैकड़ों अनुरोध सबमिट कर सकता है और उसे ध्वस्त कर सकता है। इस लेख में सुरक्षा शामिल नहीं है, लेकिन मानक सर्वोत्तम प्रक्रियाओं में शामिल हैं:

• HTTPS का उपयोग करें

• एक मजबूत प्रमाणीकरण तंत्र नियोजित करें

• CORS का उपयोग ग्राहक कॉल को विशेष क्षेत्रों में प्रतिबंधित करने के लिए किया जा सकता है।

• क्षमताओं की आवश्यकताएं प्रदान करें - अर्थात, नहीं

• DELETE विकल्प उत्पन्न करें जो आवश्यक नहीं हैं; सभी समापन बिंदु URL और मुख्य भाग की जानकारी सत्यापित करें।

• क्लाइंट-साइड जावास्क्रिप्ट में एपीआई वाउचर के अधीन न करके अज्ञात क्षेत्रों या आईपी पते से लिंक ब्लॉक करें।

• असामान्य रूप से बड़े पैकेट अवरुद्ध हैं।

• दर प्रतिबंध के बारे में सोचें, जहां समान आईपी पते या एपीआई क्रेडेंशियल से अनुरोध प्रति मिनट एन प्रश्नों तक सीमित हैं।

• उचित HTTP स्थिति कोड, कैश हेडर लॉग क्वेरी और असफल जांच के साथ प्रतिक्रिया

एकाधिक अनुरोध और अनावश्यक डेटा

RESTful वेब सेवाओं के परिनियोजन की सीमाएँ हैं। यह संभव है कि किसी प्रतिक्रिया में आपके अनुरोध से अधिक जानकारी हो या सभी जानकारी प्राप्त करने के लिए कई अनुरोधों की आवश्यकता हो। रीस्टफुल वेब सेवाओं के बारे में सोचें जो उपयोगकर्ताओं को निर्माता और पुस्तक जानकारी तक पहुंच प्रदान करती हैं; ग्राहक कर सकता है:

• खरीद के क्रम में सूचीबद्ध पहली 10 पुस्तकों की जानकारी के लिए पूछें (सबसे पहले विक्रेता)। उत्तर में प्रत्येक लेखक की आईडी के साथ पुस्तकों का एक संग्रह शामिल है।

• प्रत्येक लेखक के लिए जानकारी प्राप्त करने के लिए, अधिकतम 10 /author/id क्वेरी तैयार करें।

  मूल क्वेरी के लिए प्रत्येक प्रतिक्रिया के लिए N API क्वेरी जेनरेट की जानी चाहिए, जिसे "N+1 समस्या" के रूप में वर्णित किया गया है।

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

ऊपर लपेटकर

अब आप REST API, REST API कैसे काम करते हैं, REST API उदाहरण, REST API का उपयोग किस लिए किया जाता है, वास्तु संबंधी बाधाओं और इस ट्यूटोरियल में शामिल अन्य विषयों को अच्छी तरह से समझते हैं। प्रोग्रामर को एपीआई के बारे में सीखना मुश्किल और डराने वाला लग सकता है, लेकिन नो-कोड प्लेटफॉर्म ऐपमास्टर ने एक नई सुलभ आरईएसटी एपीआई लाइब्रेरी बनाई है जहां आप अपने आगे के पेशेवर विकास का समर्थन करने के लिए आरईएसटी एपीआई की एक श्रृंखला के बारे में अपनी जागरूकता बढ़ा सकते हैं।

AppMaster में, हम API पहुंच और उपयोगिता बढ़ाने का प्रयास करते हैं। हम चाहते हैं कि आप अपने करियर और व्यक्तिगत जीवन में एपीआई सॉफ्टवेयर का उपयोग करने के लाभों के बारे में जानें, प्रयोग करें और महसूस करें। बेहतर वेब एपीआई को तेजी से डिजाइन करने में आपकी मदद करने के लिए, ऐपमास्टर सहयोग में सुधार करता है और एपीआई जीवनचक्र के हर चरण को स्वचालित करता है। REST API की अपनी समझ को बनाना, आगे बढ़ाना और विस्तृत करना जारी रखें।