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

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

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

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

वेब एपीआई अनुरोध के भाग

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

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

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

अनुरोध आने के बाद क्या होता है

सर्वर अनुरोध प्राप्त करता है, यह जांचता है कि यह सही है या नहीं, और निर्णय लेता है कि क्या कॉलर को कार्य करने की अनुमति है या नहीं। यह डेटा पढ़ने या कार्य शुरू करने से पहले इनपुट को मान्य कर सकता है। विशेष क्रम और जाँच सेवा कार्यान्वयन को संबोधित करती हैं; क्लाइंट उन परिभाषित प्रतिक्रियाओं के माध्यम से उनके प्रभाव को देखता है। क्लाइंट-सेवर अवलोकन अनुरोध, सर्वर प्रक्रिया, और प्रतिक्रिया चक्र को दर्शाता है।

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

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

कैसे प्रतिक्रियाएँ परिणामों का संचार करती हैं

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

संरचित उत्तरों के लिए, मीडिया प्रकार महत्वपूर्ण है। एक क्लाइंट को पहले यह जांचना चाहिए कि उसने सही एंडपॉइंट पर पहुँच गया है और अपेक्षित सामग्री प्रकार प्राप्त किया है। एक HTML त्रुटि पृष्ठ एक JSON ऑब्जेक्ट नहीं है जिसमें क्षेत्र गायब हैं। इन जांचों के बिना पार्सिंग अक्सर एक द्वितीयक सिंटैक्स अपवाद के पीछे असली विफलता को छिपा देती है।

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

प्रमाणीकरण, अधिकारिता, और सीमाएँ

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

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

Scrapeless अपनी मुख्य हैंडलिंग को समझाता है। एपीआई कुंजी मार्गदर्शनप्रदाता-विशिष्ट शीर्षक और संचालन विवरण वर्तमान उत्पाद दस्तावेज़ीकरण में होना चाहिए। एक वास्तविक अनुप्रयोग में सर्वर-साइड रहस्य स्टोर या नियंत्रणित वातावरण परिवर्तनीय का उपयोग करें; सार्वजनिक उदाहरण में काम करने वाले निजी क्रेडेंशियल नहीं होना चाहिए।

एक ठोस स्क्रैपिंग एपीआई उदाहरण

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

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

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

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

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

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

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

निष्कर्ष

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