छिपा हुआ API HTML के बजाय: पार्सिंग ट्रैफ़िक में 10 गुना बचत

यदि आप Wildberries, Ozon या किसी अन्य वेबसाइट को पूर्ण HTML पृष्ठों को लोड करके पार्स कर रहे हैं, तो आप प्रॉक्सी ट्रैफ़िक के लिए 5-10 गुना अधिक भुगतान कर रहे हैं जितना कि आपको करना चाहिए। प्रत्येक उत्पाद कार्ड का पृष्ठ 200-800 KB मार्कअप, स्क्रिप्ट और शैलियों का होता है, जिनमें से आपको वास्तव में केवल कुछ फ़ील्ड की आवश्यकता होती है: कीमत, उपलब्धता, रेटिंग। इस लेख में हम समझाते हैं कि वेबसाइट का छिपा हुआ API कैसे खोजें और सीधे, कॉम्पैक्ट JSON प्रारूप में वही डेटा प्राप्त करें।

क्यों HTML पार्सिंग प्रॉक्सी ट्रैफ़िक को खा जाता है

जब पार्सर सामान्य HTTP अनुरोध या हेडलेस ब्राउज़र (Selenium, Puppeteer, Playwright) के माध्यम से पृष्ठ लोड करता है, तो सर्वर पूर्ण HTML दस्तावेज़ देता है: मार्कअप, इनलाइन स्क्रिप्ट, शैलियाँ, कभी-कभी base64 छवियाँ और विज्ञापन विजेट्स के लिए डेटा के सैकड़ों पंक्तियाँ, जिनकी आपको आवश्यकता नहीं होती। Wildberries पर औसत उत्पाद कार्ड का वजन 300-600 KB है, Ozon पर - 800 KB तक, यदि सभी संबंधित संसाधनों (CSS, फ़ॉन्ट, ट्रैकर्स) को गिना जाए।

यदि आप 10,000 उत्पादों की निगरानी दिन में 3 प्रॉक्सी सत्रों के माध्यम से करते हैं, तो यह आसानी से महीने में दर्जनों गीगाबाइट ट्रैफ़िक में बदल जाता है। निवासीय और मोबाइल प्रॉक्सी आमतौर पर ट्रैफ़िक के आधार पर बेचे जाते हैं, इसलिए प्रत्येक अतिरिक्त मेगाबाइट सीधे खर्च होते हैं। इस बीच, वास्तविक डेटा, जिसकी आपको आवश्यकता है - कीमत, छूट, स्टॉक, रेटिंग - JSON प्रतिक्रिया में 1-5 KB लेती है। एक उत्पाद पर मात्रा में 100-200 गुना का अंतर होता है, और ब्राउज़र के रेंडरिंग पर ओवरहेड को ध्यान में रखते हुए, समय और CPU की बचत और भी अधिक होती है।

HTML पार्सिंग की एक अतिरिक्त समस्या - नाजुकता। मार्केटप्लेस वेबसाइटें नियमित रूप से लेआउट, CSS क्लास, DOM संरचना को बदलती हैं। प्रत्येक ऐसा परिवर्तन XPath या CSS चयनकर्ताओं पर आधारित पार्सर को तोड़ देता है। आंतरिक API बहुत कम बदलता है, क्योंकि यह मोबाइल एप्लिकेशन और वेबसाइट के फ्रंटएंड दोनों के काम पर निर्भर करता है।

छिपा हुआ API क्या है और यह कहां से आता है

लगभग हर आधुनिक वेबसाइट एक SPA (सिंगल पेज एप्लिकेशन) या हाइब्रिड एप्लिकेशन है, जहां ब्राउज़र पहले "हड्डी" पृष्ठ को लोड करता है, और फिर JavaScript के माध्यम से आंतरिक API से वास्तविक डेटा: कीमतों, स्टॉक्स, समीक्षाओं, सिफारिशों के लिए अतिरिक्त अनुरोध करता है। इन अनुरोधों को छिपे हुए या आंतरिक API कहा जाता है - ये सार्वजनिक रूप से प्रलेखित नहीं होते हैं, लेकिन ब्राउज़र के ट्रैफ़िक में पूरी तरह से खुले होते हैं।

तकनीकी रूप से, ये आमतौर पर REST या GraphQL एंडपॉइंट होते हैं, जो डेटा को JSON प्रारूप में देते हैं। उदाहरण के लिए, Wildberries पर उत्पाद कार्ड card.wb.ru और wbx-content-v2.wbstatic.net जैसे अनुरोधों के माध्यम से लोड होता है, और कीमतें और स्टॉक्स basket-01.wb.ru और समान डोमेन पर अलग अनुरोध के माध्यम से आती हैं। Ozon में समान तर्क है: फ्रंटएंड आंतरिक कंपोज़र API पर जाता है, जो माइक्रोसर्विसेज से डेटा को समेकित करता है।

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

DevTools के माध्यम से छिपा हुआ API कैसे खोजें

बिना एक भी कोड की पंक्ति के आंतरिक API को खोजा जा सकता है, Chrome या Firefox के अंतर्निहित उपकरणों का उपयोग करके। यहां चरण-दर-चरण एल्गोरिदम है:

Chrome में आवश्यक उत्पाद पृष्ठ खोलें, F12 दबाएं और Network टैब पर जाएं।
अनुरोधों के फ़िल्टर में Fetch/XHR प्रकार चुनें - इससे आप छवियों, फ़ॉन्ट और स्थैतिक सामग्री के लोड को काट देंगे।
पृष्ठ को पुनः लोड करें (F5) और उन अनुरोधों की सूची देखें जो पृष्ठ की हड्डी लोड होने के बाद प्रकट हुए।
उस अनुरोध को खोजें, जिसके उत्तर में (Response टैब) उत्पाद की कीमत, नाम या अन्य आवश्यक फ़ील्ड JSON प्रारूप में दिखाई देती हैं।
इस अनुरोध पर क्लिक करें और इसे cURL के रूप में कॉपी करें (दाएँ क्लिक → कॉपी → cURL के रूप में कॉपी करें) - यह आपको पूर्ण सेट हेडर, कुकीज़ और पैरामीटर देगा।
जांचें कि URL में कौन से पैरामीटर अनिवार्य हैं (उत्पाद का आर्टिकल, क्षेत्र, API का संस्करण), और कौन से डेटा खोए बिना हटा सकते हैं।

इसके बाद, इस अनुरोध को सामान्य HTTP पुस्तकालय के माध्यम से दोहराना पर्याप्त है, आवश्यक आर्टिकल या उत्पाद ID को डालकर, बजाय इसके कि पूरे पृष्ठ को पूरी तरह से रेंडर करें। यह अधिकांश मार्केटप्लेस - Wildberries, Ozon, Avito, और कई विदेशी प्लेटफार्मों जैसे Amazon और eBay के लिए काम करता है।

ट्रैफ़िक की तुलना: HTML बनाम JSON API

डेटा के आकार में अंतर इतना बड़ा है कि इसे संख्याओं में दिखाना उचित है। नीचे - लोकप्रिय मार्केटप्लेस पर एक उत्पाद कार्ड के लिए औसत माप।

पार्सिंग का तरीका	उत्तर का औसत आकार	लोडिंग का समय	JS रेंडरिंग की आवश्यकता है
Selenium के माध्यम से पूर्ण HTML	400-800 KB	1.5-4 सेकंड	हाँ
सरल HTTP अनुरोध (requests)	150-300 KB	0.3-0.8 सेकंड	नहीं
छिपा हुआ JSON API	3-15 KB	0.1-0.3 सेकंड	नहीं

यदि आप दिन में 50,000 उत्पादों की निगरानी कर रहे हैं, तो हेडलेस ब्राउज़र से API के लिए सीधे अनुरोधों पर स्विच करना ट्रैफ़िक को लगभग 30-40 GB से 300-700 MB प्रति माह तक कम कर देता है। यह न केवल प्रॉक्सी ट्रैफ़िक पर बचत है, बल्कि पार्सर की सर्वर इंफ्रास्ट्रक्चर पर लोड को भी कम करता है - रेंडरिंग के लिए कम CPU, कम मेमोरी, डेटा संग्रह में तेजी।

Python में व्यावहारिक उदाहरण

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

import requests

def get_product_data(product_id: str, proxies: dict = None) -> dict:
    """
    पूर्ण HTML के बजाय आंतरिक API के माध्यम से उत्पाद डेटा प्राप्त करता है।
    proxies - प्रॉक्सी के लिए शब्दकोश requests के प्रारूप में: {"http": "...", "https": "..."}
    """
    url = f"https://card.example-marketplace.ru/v2/detail"
    params = {
        "nm": product_id,
        "dest": "-1257786",  # क्षेत्र, DevTools के माध्यम से निर्धारित किया जाता है
        "spp": "0"
    }
    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                       "AppleWebKit/537.36 (KHTML, like Gecko) "
                       "Chrome/120.0 Safari/537.36",
        "Accept": "application/json",
        "Referer": f"https://www.example-marketplace.ru/catalog/{product_id}/detail.aspx"
    }

    response = requests.get(
        url,
        params=params,
        headers=headers,
        proxies=proxies,
        timeout=10
    )
    response.raise_for_status()
    data = response.json()

    product = data["products"][0]
    return {
        "id": product["id"],
        "name": product["name"],
        "price": product["salePriceU"] / 100,
        "stock": product.get("totalQuantity", 0),
        "rating": product.get("reviewRating", None)
    }


if __name__ == "__main__":
    proxy = {
        "http": "http://user:pass@proxy-host:port",
        "https": "http://user:pass@proxy-host:port"
    }
    result = get_product_data("123456789", proxies=proxy)
    print(result)

इस उदाहरण में तीन बिंदुओं पर ध्यान दें। सबसे पहले, हम Referer हेडर निर्दिष्ट करते हैं, क्योंकि कई API यह जांचते हैं कि अनुरोध "ब्राउज़र से" आया है, न कि सीधे URL के माध्यम से। दूसरे, हम एक यथार्थवादी User-Agent का उपयोग करते हैं, न कि requests पुस्तकालय से डिफ़ॉल्ट, जिसे आसानी से पहचान लिया जाता है। तीसरे, पूरा अनुरोध एक HTTP कॉल में समाहित होता है बिना रेंडरिंग के - यह ट्रैफ़िक और गति में गुणात्मक लाभ देता है।

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

API अनुरोधों के लिए प्रॉक्सी के साथ काम करना

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

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

उन API के लिए जो मोबाइल ऐप पर निर्भर करते हैं (कुछ संस्करणों के एंडपॉइंट केवल मोबाइल ट्रैफ़िक पर डेटा देते हैं), मोबाइल प्रॉक्सी के माध्यम से कनेक्शन की आवश्यकता हो सकती है - ये वास्तविक मोबाइल ऑपरेटरों के ट्रैफ़िक की नकल करते हैं और उन परीक्षणों को पास करते हैं जो सामान्य IP को ब्लॉक करते हैं।

पार्सर में प्रॉक्सी सेट करते समय यह भी महत्वपूर्ण है कि अनुरोधों को समय के अनुसार फैलाया जाए और IP रोटेशन का उपयोग किया जाए - यहां तक कि एक कॉम्पैक्ट JSON अनुरोध, जो एक ही पते से प्रति मिनट 1000 बार दोहराया जाता है, सुरक्षा प्रणाली को संदेह में डाल देगा। कई प्रॉक्सी सत्रों का एक पूल सेट करें और उनके बीच लोड वितरित करें, अनुरोधों के बीच 1-3 सेकंड की यादृच्छिक देरी जोड़ें।

पार्श्व समस्याएं: टोकन, हस्ताक्षर, एंटी-बॉट

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

सत्र के लिए अस्थायी टोकन - कुछ API एक टोकन के लिए पूर्व अनुरोध की आवश्यकता होती है, जिसे फिर अगले अनुरोधों के हेडर में भेजा जाता है और सीमित समय (आमतौर पर 5-30 मिनट) के लिए जीवित रहता है।
अनुरोध का हस्ताक्षर (signature) - अनुरोध के पैरामीटर को पृष्ठ के JS कोड से गुप्त कुंजी के साथ क्लाइंट पर हैश किया जाता है। इस हस्ताक्षर को या तो मैन्युअल रूप से पुन: उत्पन्न करना होगा, एल्गोरिदम को समझकर, या केवल टोकन प्राप्त करने के चरण में हेडलेस ब्राउज़र के माध्यम से निष्पादित करना होगा, और फिर सीधे हल्के अनुरोध भेजना होगा।
IP और User-Agent के अनुसार दर सीमित करना - जब अनुरोधों की आवृत्ति को पार किया जाता है, तो वेबसाइट अस्थायी रूप से पहुंच को ब्लॉक करती है। इसे प्रॉक्सी के रोटेशन और समझदारी से देरी के साथ हल किया जा सकता है।
हेडर की फिंगरप्रिंटिंग - कुछ सिस्टम पूर्ण हेडर सेट (क्रम, Accept-Language, Sec-Fetch-* की उपस्थिति) की जांच करते हैं और "अपूर्ण" सेट के साथ अनुरोधों को ब्लॉक करते हैं, जो स्क्रिप्ट के लिए विशिष्ट होते हैं, न कि ब्राउज़रों के लिए।
डेटा की भूगोल-निर्भरता - मार्केटप्लेस पर कीमतें और स्टॉक्स क्षेत्रों के अनुसार भिन्न हो सकते हैं, इसलिए अनुरोध में सही क्षेत्र/गोदाम पैरामीटर भेजना महत्वपूर्ण है, अन्यथा डेटा अप्रासंगिक होगा।

यदि API अनुरोध के हस्ताक्षर के माध्यम से बंद है, जिसे पुन: उत्पन्न करना कठिन है, तो एक समझौता विकल्प है - नेटवर्क अनुरोधों को पकड़ने और तैयार JSON प्रतिक्रिया निकालने के लिए हेडलेस ब्राउज़र (Playwright, Puppeteer) का उपयोग करना, बिना DOM पार्सिंग के। यह सीधे HTTP अनुरोध की तुलना में धीमा है, लेकिन फिर भी पृष्ठ के लेआउट के पूर्ण पार्सिंग की तुलना में तेज और आसान है।

छिपे हुए API पर पार्सर शुरू करने से पहले चेकलिस्ट

DevTools के माध्यम से एंडपॉइंट पाया गया, cURL के रूप में कॉपी किया गया और Postman या requests के माध्यम से परीक्षण किया गया।
अनुरोध के अनिवार्य पैरामीटर (उत्पाद ID, क्षेत्र, API का संस्करण) निर्धारित किए गए और अतिरिक्त हटा दिए गए।
User-Agent, Referer और Accept-Language हेडर को यथार्थवादी रूप से सेट किया गया।
जांच की गई कि क्या सत्र का टोकन या अनुरोध का हस्ताक्षर आवश्यक है, और उन्हें प्राप्त करने का तरीका सोचा गया।
प्रॉक्सी का रोटेशन और अनुरोधों के बीच यादृच्छिक देरी सेट की गई।
विशिष्ट वेबसाइट की सुरक्षा के लिए उपयुक्त प्रॉक्सी प्रकार चुना गया - डेटा सेंटर, निवासीय या मोबाइल।
429 और 403 त्रुटियों को संभालने के लिए स्वचालित रूप से दूसरे प्रॉक्सी पर स्विच करने की प्रक्रिया जोड़ी गई।
वास्तविक बचत की निगरानी के लिए ट्रैफ़िक की मात्रा का लॉगिंग सेट किया गया।

निष्कर्ष

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

इस बीच, API खोजने की विधि उच्च गुणवत्ता वाली प्रॉक्सी की आवश्यकता को समाप्त नहीं करती है - मार्केटप्लेस की एंटी-बॉट सिस्टम HTML अनुरोधों और JSON एंडपॉइंट्स दोनों पर समान रूप से ध्यान देती हैं। यदि आप Wildberries या Ozon की बड़ी मात्रा में निगरानी कर रहे हैं, तो लागत को कम करने के लिए तेज डेटा सेंटर प्रॉक्सी से शुरू करें, और जब पहली बार ब्लॉक के संकेत दिखाई दें, तो अधिक स्थिर पार्सर संचालन के लिए निवासीय या मोबाइल IP पूल पर स्विच करें।