REST API क्या है?

Scrapeless Scraping API दस्तावेज़ीकृत HTTP कार्यों को उजागर करता है जो अनुप्रयोगों का उपयोग करना Structured वेब डेटा का अनुरोध करने के लिए।

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

कई सेवाएँ REST APIs कहलाती हैं क्योंकि वे HTTP और JSON का उपयोग करती हैं। केवल ये अवयव परिभाषा नहीं हैं। उपयोगी सवाल यह है कि इंटरफ़ेस संसाधन पहचान, मानक विधि अर्थ, Stateless इंटरैक्शन, कैश जानकारी, और अनुप्रयोग राज्यों के बीच लिंक का उपयोग कैसे करता है। उन विकल्पों पर नज़र डालना एक टीम को बिना लेबल पर बहस किए एक मौजूदा API का आकलन करने में मदद करता है।

संसाधन और प्रतिनिधित्व

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

एक क्लाइंट एक रिपोर्ट संसाधन का अनुरोध कर सकता है और अपनी स्थिति और लिंक के साथ JSON प्राप्त कर सकता है। दूसरा क्लाइंट एक अलग प्रतिनिधित्व प्राप्त कर सकता है यदि API इसका समर्थन करता है। संसाधन पहचान स्थिर रहती है जबकि प्रतिनिधित्व समय के साथ बदल सकता है। यह भेद यह समझाने में मदद करता है कि एक API को पहचानकर्ताओं और मीडिया प्रकारों के अर्थ का दस्तावेज़ीकरण क्यों करना चाहिए, न कि यह मान लेना कि हर JSON ऑब्जेक्ट स्वयं संसाधन है।

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

समान इंटरफ़ेस और HTTP विधियाँ

REST एक समान इंटरफ़ेस पर जोर देता है: घटक सामान्य संदेश अर्थ के माध्यम से बातचीत करते हैं न कि प्रत्येक वस्तु के लिए एक अलग कस्टम कमांड भाषा। HTTP GET, POST, PUT, PATCH, और DELETE जैसी विधियाँ प्रदान करता है, लेकिन चुनी हुई विधि को वास्तविक संचालन से मेल खाना चाहिए। HTTP अर्थों का मानक विधि के अर्थ और संबंधित प्रतिक्रिया गुणों को परिभाषित करता है।

GET का उद्देश्य एक प्रतिनिधित्व प्राप्त करना है बिना स्थिति परिवर्तन के अनुरोध किए। एक पढ़ने-केवल एंडपॉइंट जो गुप्त रूप से एक ऑर्डर को चार्ज करता है या एक रिकॉर्ड को मिटाता है वह क्लाइंट की अपेक्षाओं का उल्लंघन करता है भले ही इसका URL व्यवस्थित लगे। POST संसाधन की अर्थों के तहत प्रसंस्करण का समर्थन करता है; PUT एक लक्षित संसाधन प्रतिनिधित्व के प्रतिस्थापन को व्यक्त करता है। सही विकल्प वास्तविक अनुबंध पर निर्भर करता है, न कि एक मेमोराइज टेबल जो डिज़ाइन दस्तावेज़ में कॉपी की गई है।

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

Stateless इंटरैक्शन और एप्लिकेशन स्थिति

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

प्रमाणीकरण अभी भी हो सकता है। एक क्लाइंट प्रत्येक अनुरोध पर एक क्रेडेंशियल भेज सकता है जबकि सर्वर एक उपयोगकर्ता डेटाबेस बनाए रखता है। एक कर्सर या कार्य पहचानकर्ता भी पहले बनाए गए संसाधन की पहचान कर सकता है, जब तक कि नया अनुरोध इसकी संदर्भ को स्पष्ट करता है। सीमा मायने रखती है: एक सर्वर क्लाइंट से “चरण दो” जारी करने के लिए कहता है जबकि यह याद रखता है कि कौन सा नामांकित संचालन “चरण एक” ने संदर्भित किया, एक छिपा हुआ सत्र युग्मन बनाता है।

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

कैशिंग और प्रतिक्रिया का अर्थ

REST कैश बाधाओं को शामिल करता है क्योंकि पुन: उपयोग योग्य प्रतिक्रियाएँ नेटवर्क के कार्य को कम कर सकती हैं। सर्वर को संवाद करना चाहिए कि कब एक प्रतिनिधित्व को फिर से उपयोग किया जा सकता है और किस शर्तों के तहत। HTTP कैशिंग गाइड ताजगी और प्रमाणीकरण तंत्र की व्याख्या करता है। एक API जो JSON लौटाता है, जब डेटा और प्रमाणन मॉडल इसकी अनुमति देते हैं, तब कैश नियंत्रण से लाभ उठा सकता है।

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

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

REST, RPC, और कार्य-उन्मुख डेटा APIs

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

यह Scrapeless Scraping API परिचय संरचित डेटा के लिए अभिनेता-चयनित संचालन का वर्णन करता है। इसका अनुरोध एक कार्य चुनने के लिए एक अभिनेता का उपयोग करता है। उस ठोस इंटरफ़ेस का वर्णन उसके प्रलेखित HTTP अनुबंध द्वारा किया जाना चाहिए; इसे पाठ्यपुस्तक REST लेबल में मजबूर नहीं किया जाना चाहिए। क्लाइंट कोड को वास्तविक संचालन, इनपुट, और परिणाम रूपों का पालन करना चाहिए।

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

REST API अनुबंध की समीक्षा कैसे करें

एक प्रतिनिधि कार्यप्रवाह लें और उसके द्वारा छुए गए संसाधनों को खींचें। प्रत्येक संसाधन के लिए URL, अनुमत विधियाँ, प्रतिनिधित्व क्षेत्र, और अपेक्षित विफलता मामलों के लिए स्थिति कोड की पहचान करें। फिर पूछें कि क्या एक अनुरोध स्वतंत्र रूप से समझा जा सकता है। यह अभ्यास उस पर निर्भर करने से अधिक उपयोगी है कि कितनी URL पथों में संज्ञाएँ हैं।

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

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

निष्कर्ष

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