API क्या है?

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

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

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

इंटरफेस एक संविदा है

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

The OpenAPI विशिष्टता टीमों को HTTP API पथों, संचालन, पैरामीटर, अनुरोध शरीर, प्रतिक्रियाएँ, और सुरक्षा स्कीमों का वर्णन करने के लिए एक मशीन-पठनीय तरीका प्रदान करता है। एक वर्णन दस्तावेज़ टूलिंग में मदद करता है, लेकिन यह सेवा का अवलोकन करने का विकल्प नहीं है। उदाहरण वैकल्पिक क्षेत्रों या असाधारण मामलों को छोड़ सकते हैं। विनिर्देशन की तुलना एक वास्तविक प्रतिक्रिया के साथ करें और स्वीकृति परीक्षणों को उन क्षेत्रों से जोड़े रखें जो अनुप्रयोग वास्तव में उपयोग करता है।

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

कैसे एक वेब एपीआई कॉल HTTP के माध्यम से चलता है

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

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

परिवहन, HTTP परिणाम, और व्यवसाय परिणाम को अलग से लॉग किया जाना चाहिए। एक DNS विफलता का मतलब है कि कोई HTTP प्रतिक्रिया नहीं आई। एक HTTP 401 का मतलब है कि सेवा ने प्रमाणीकरण को अस्वीकार कर दिया। एक सफल HTTP प्रतिक्रिया अभी भी एक खाली या अधूरे व्यवसाय परिणाम को शामिल कर सकती है। उन स्तरों को अलग रखकर परिचालन निदान संभव बनाता है और कोड को चुपचाप लॉगिन पृष्ठ को निकाले गए रिकॉर्ड के रूप में संग्रहीत करने से रोकता है।

API के प्रकार और कब प्रत्येक उपयुक्त है

एक पुस्तकालय एपीआई एक स्थानीय प्रोग्रामिंग इंटरफेस है: कार्य और प्रकार एक प्रक्रिया के भीतर कॉल किए जाते हैं। एक ब्राउज़र एपीआई पृष्ठ कोड के लिए DOM चयन या नेटवर्क अनुरोधों जैसी क्षमताएं उजागर करता है। एक ऑपरेटिंग-सिस्टम एपीआई फ़ाइलों, प्रक्रियाओं, या उपकरणों को उजागर करता है। एक रिमोट एपीआई एक नेटवर्क सीमा को पार करता है। साझा विशेषता यह है कि एक घटक का दूसरा का उपयोग करने का एक दस्तावेजीकृत तरीका है; शब्द एपीआई अकेले JSON, REST, या यहां तक कि HTTP का संकेत नहीं देता है।

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

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

प्रमाणीकरण, प्राधिकरण, और त्रुटि का अर्थ

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

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

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

एक ठोस स्क्रेपलेस एपीआई का उदाहरण

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

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

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

एक एपीआई पर निर्भर होने से पहले इसका मूल्यांकन कैसे करें

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

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

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

निष्कर्ष

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