कैसे ब्राउज़र डेवलपर टूल्स के साथ हिडन एपीआई खोजें और स्क्रेप करें

TL;DR:

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

कई JavaScript पृष्ठ उनके वास्तविक सामग्री को दस्तावेज़ लोड होने के बाद फ़ेच करते हैं। प्रदर्शित कार्ड पहले से ही ब्राउज़र के नेटवर्क पैनल में दृष्टिगोचर एक संरचित प्रतिक्रिया का केवल एक प्रेजेंटेशन होते हैं।

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

What Is a Hidden API?

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

सामान्य प्रतिक्रिया आकृतियाँ शामिल हैं:

• JSON वस्तुएँ या सरणियाँ;
• GraphQL प्रतिक्रिया लिफाफे;
• HTML फ़्रैगमेंट जो पृष्ठ में डाले जाते हैं;
• न्यूलाइन-सीमांकित इवेंट स्ट्रीम;
• बाइनरी प्रारूप जिन्हें साइट के अपने डिकोडर की आवश्यकता होती है।

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

DOM Scraping vs Internal JSON Requests

सही स्रोत वह है जो अनुमोदित क्षेत्रों को सबसे छोटे स्थिर अनुबंध के साथ लौटाता है।

जब पृष्ठ की अपनी प्रस्तुति प्राधिकृत स्रोत होती है या जब अनुरोध अनुबंध बहुत नाजुक होता है, तब DOM का उपयोग करें। जब यह आवश्यक सार्वजनिक क्षेत्रों को साफ-सुथरा पेश करता है और कार्यप्रवाह समान पहुंच सीमाओं का सम्मान कर सकता है, तब आंतरिक प्रतिक्रिया का उपयोग करें।

Step 1 — Open DevTools Before the Page Action

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

The Chrome DevTools Network reference लॉग को बनाए रखना, अनुरोध-प्रकार फ़िल्टर, पेलोड निरीक्षण, प्रतिक्रिया पूर्वावलोकन, प्रारंभकर्ता, HAR निर्यात, और Fetch या cURL के रूप में कॉपी करने के दस्तावेज़ करता है।

अब एक ऐसा कार्य करें जो डेटा लोड करता है:

• एक सार्वजनिक खोज सबमिट करें;
• एक श्रेणी बदलें;
• अगले परिणाम पृष्ठ को लोड करें;
• एक सार्वजनिक विवरण पैनल को विस्तारित करें;
• अगली बैच दिखाई देने तक स्क्रॉल करें।

एक क्रिया एक छोटा, ऑडिटेबल अनुरोध अंतर बनाती है बजाय इसके कि पूरे पृष्ठ के साथ पहले संपर्क किया जाए।

Step 2 — Filter Fetch/XHR and Find the Data-Bearing Response

Fetch/XHR का चयन करें, फिर उन अनुरोधों का निरीक्षण करें जिनका समय पृष्ठ क्रिया के साथ मेल खाता है। उस एक स्थिर सार्वजनिक मान के लिए प्रतिक्रिया निकायों की खोज करें जो पृष्ठ पर दिखाई देता है, जैसे कि आइटम आईडी, सटीक शीर्षक, या श्रेणी कोड।

इन क्षेत्रों की जांच करें:

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

चरण 3 — तय करें कि अनुरोध को फिर से करना सुरक्षित है या नहीं

एक पुनरुत्पादनीय अनुरोध को उसी प्राधिकरण सीमा के भीतर रहना चाहिए जैसे कि पृष्ठ।

जब आगे बढ़ें:

• प्रतिक्रिया में सार्वजनिक डेटा हो जिसे उपयोगकर्ता एक खाता बिना एक्सेस कर सके;
• अनुरोध एक स्पष्ट रूप से अधिकृत एकीकरण या परीक्षण का हिस्सा हो;
• अपेक्षित मात्रा अनुपात में हो;
• दिए गए डेटा सेट के लिए फ़ील्ड आवश्यक हो।

जब रुकें:

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

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

चरण 4 — अनुरोध की कॉपी बनाएँ, फिर इसे कम करें

DevTools एक अनुरोध को cURL या Node.js फ़ेच कॉल के रूप में कॉपी कर सकता है। उस आउटपुट को एक नैदानिकsnapshot के रूप में मानें, न कि उत्पादन कोड के रूप में।

इस क्रम में हटाएँ:

1. ट्रैकिंग और ब्राउज़र-जनित हेडर;
2. सार्वजनिक प्रतिनिधित्व से अप्रासंगिक कुकीज़;
3. एक बार के सह-संबंध मान;
4. पैरामीटर जो आवश्यक परिणाम को नहीं बदलते हैं;
5. अनावश्यक सामग्री समझौता हेडर।

प्रत्येक परिवर्तन के बाद, प्रतिक्रिया स्कीमा और आवश्यक रिकॉर्ड का मान्य करें। लक्ष्य एक न्यूनतम अनुरोध संविदा है जिसे क्षेत्र-दर-क्षेत्र समझाया जा सके।

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

चरण 5 — प्रतिक्रिया को एक स्थिर स्कीमा में मैप करें

आंतरिक प्रतिक्राएँ अक्सर उन क्षेत्रों को उजागर करती हैं जिनकी डेटा सेट को आवश्यकता नहीं होती है। एक संकीर्ण आउटपुट संविदा को परिभाषित करें।

{
  "source_url": "https://example.com/public-search?q=notebook",
  "query": "notebook",
  "page": {
    "cursor": "next-public-cursor",
    "has_more": true
  },
  "items": [
    {
      "id": "item-123",
      "title": "Illustrative public result",
      "url": "https://example.com/public/items/item-123",
      "price": null
    }
  ]
}

ऊपर का स्कीमा एक चित्रात्मक नमूना है। नल होने वाले क्षेत्रों को नल रखें, स्रोत URL को बनाए रखें, और एक स्थिर पहचानकर्ता को संरक्षित करें जब प्रतिक्रिया एक प्रदान करती है।

जब खोज के लिए JavaScript और ब्राउज़र स्थिति की आवश्यकता हो, तो एक मुफ्त Scrapeless Scraping Browser सत्र शुरू करें।

चरण 6 — स्केलिंग से पहले पृष्ठीकरण को समझें

पृष्ठीकरण अक्सर चार जगहों में से एक में प्रकट होता है:

• एक page संख्या क्वेरी में;
• एक offset प्लस एक निश्चित सीमा;
• प्रतिक्रिया में एक अपारदर्शी कर्सर;
• अनुरोध शरीर में एक GraphQL चर।

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

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

चरण 7 — जब अनुरोध को इसकी आवश्यकता हो तो सत्र स्थिति रखें

कुछ आंतरिक अनुरोध तभी काम करते हैं जब पृष्ठ कुकीज़, सहमति, स्थानीयता, या अन्य अनुमत स्थिति स्थापित करता है। उस स्थिति में, खोज और निष्कर्षण को एक सीमित ब्राउज़र सत्र में रखें।

Scrapeless Scraping Browser एक क्लाउड ब्राउज़र में JavaScript चलाता है और अनुमोदित नेविगेशन के बीच सत्र स्थिति बनाए रखता है। इसका उपयोग अनुरोध को अवलोकन करने और उसी संदर्भ से प्रतिक्रिया निकालने के लिए करें, न कि किसी अप्रासंगिक ग्राहक में अपारदर्शी स्थिति को निर्यात करने के लिए।

Scrapeless Scraping Browser दस्तावेज़ीकरण सीमित सत्र जीवनकाल और भौगोलिक रूटिंग पैरामीटर को दस्तावेजित करता है। अनुरोध का मान्यकरण करते समय भूगोल, भाषा, कुकीज़, और पृष्ठ अनुक्रम को स्थिर रखें।

ब्राउज़र बैकफॉल: जब आंतरिक API गलत स्रोत हो

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

जब प्रदर्शित DOM निष्कर्षण चुनें:

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

छिपे हुए एपीआई स्क्रैपिंग के लिए समस्या निवारण

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

निष्कर्ष: अनुरोध अनुबंध को एक निर्भरता के रूप में मानें

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

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

क्या आप एक ब्राउज़र-जानकार निष्कर्षण कार्यप्रवाह बनाने के लिए तैयार हैं?

सार्वजनिक-data खोज और स्कीमा डिज़ाइन पर चर्चा करने के लिए Scrapeless समुदाय में शामिल हों: Discord · Telegram.

Scrapeless मूल्य निर्धारण की समीक्षा करें, फिर app.scrapeless.com पर मुफ्त Scraping Browser रUNTIME के लिए साइन अप करें।

सामान्य प्रश्न

प्रश्न: क्या छिपे हुए एपीआई को स्क्रैप करना कानूनी है?

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

प्रश्न: क्या छिपा हुआ एपीआई सार्वजनिक एपीआई के समान है?

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

प्रश्न: क्या छिपे हुए एपीआई का निरीक्षण करने के लिए आपको एक प्रॉक्सी की आवश्यकता है?

स्थानीय DevTools निरीक्षण के लिए प्रॉक्सी की आवश्यकता नहीं है, लेकिन अनुमोदित स्थान-विशिष्ट डेटासेट या अनुपातिक संग्रह कार्यप्रवाह के लिए आवश्यक हो सकता है।

प्रश्न: जब एक आंतरिक अनुरोध पहुँच-निषेधित पृष्ठ को लौटाता है तो आपको क्या करना चाहिए?

रुके और लौटाई गई प्रस्तुति, अधिकृतता सीमा, और परियोजना दायरे का निरीक्षण करें; किसी भिन्न हेडर या टोकन को अनुमति के रूप में न मानें।

प्रश्न: आप DOM या स्कीमा परिवर्तनों को कैसे संभालते हैं?

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

प्रश्न: छिपे हुए एपीआई स्क्रैपर को कितनी समवर्तीता रखनी चाहिए?

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

प्रश्न: क्या यह कार्यप्रवाह बिना AI एजेंट के चल सकता है?

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