API مخفي بدلاً من HTML: توفير في حركة مرور التحليل بمقدار 10 مرات

إذا كنت تقوم بتحليل Wildberries أو Ozon أو أي موقع آخر من خلال تحميل صفحات HTML كاملة، فأنت تدفع مقابل حركة مرور البروكسي بمقدار 5-10 مرات أكثر مما يمكنك. كل صفحة منتج تحتوي على 200-800 كيلوبايت من التعليمات البرمجية، والسكريبتات، والأنماط، التي تحتاج منها حرفيًا إلى بعض الحقول: السعر، التوافر، التقييم. في هذه المقالة، نحلل كيفية العثور على واجهة برمجة التطبيقات المخفية للموقع والحصول على نفس البيانات مباشرة، بتنسيق JSON مضغوط.

لماذا يأخذ تحليل HTML حركة مرور البروكسي

عندما يقوم المحلل بتحميل صفحة من خلال طلب HTTP عادي أو من خلال متصفح بدون واجهة (Selenium، Puppeteer، Playwright)، يقوم الخادم بإرجاع وثيقة HTML كاملة: التعليمات البرمجية، السكريبتات المضمنة، الأنماط، وأحيانًا صور base64 ومئات الأسطر من JSON مع البيانات الخاصة بالويدجت الإعلانية التي لا تحتاجها. متوسط بطاقة المنتج على Wildberries يزن 300-600 كيلوبايت، وعلى Ozon يصل إلى 800 كيلوبايت، إذا أخذنا في الاعتبار جميع الموارد المرتبطة (CSS، الخطوط، المتعقبين).

إذا كنت تراقب 10,000 منتج مرة واحدة في اليوم من خلال 3 جلسات بروكسي، فإن ذلك يتحول بسهولة إلى عشرات الجيجابايت من حركة المرور في الشهر. عادةً ما يتم بيع البروكسي السكنية والمحمولة بناءً على حركة المرور، لذا فإن كل ميغابايت إضافية تعني تكاليف مباشرة. في حين أن البيانات الحقيقية التي تحتاجها - السعر، الخصم، المخزون، التقييم - تشغل في استجابة JSON 1-5 كيلوبايت. الفرق في الحجم يصل إلى 100-200 مرة لكل منتج، ومع الأخذ في الاعتبار النفقات العامة على عرض المتصفح - فإن التوفير في الوقت وCPU يكون أكبر بكثير.

مشكلة إضافية في تحليل HTML هي الهشاشة. تقوم مواقع الأسواق بتغيير التنسيق، والفئات CSS، وبنية DOM بانتظام. كل تغيير من هذا القبيل يكسر المحلل المبني على XPath أو محددات CSS. تتغير واجهة برمجة التطبيقات الداخلية بشكل أقل تكرارًا، لأن عملها يعتمد على تطبيق الهاتف المحمول وواجهة الموقع في نفس الوقت.

ما هي واجهة برمجة التطبيقات المخفية ومن أين تأتي

تقريبًا كل موقع حديث هو SPA (تطبيق صفحة واحدة) أو تطبيق هجين، حيث يقوم المتصفح أولاً بتحميل "هيكل" الصفحة، ثم من خلال JavaScript يقوم بإجراء طلبات إضافية إلى واجهة برمجة التطبيقات الداخلية للحصول على البيانات الحقيقية: الأسعار، المخزونات، التعليقات، التوصيات. تُعرف هذه الطلبات بواجهات برمجة التطبيقات المخفية أو الداخلية - فهي غير موثقة علنًا، ولكنها مفتوحة تمامًا في حركة مرور المتصفح.

تقنيًا، عادةً ما تكون هذه نقاط نهاية REST أو GraphQL، التي تعيد البيانات بتنسيق JSON. على سبيل المثال، يتم تحميل بطاقة المنتج على Wildberries من خلال طلبات مثل card.wb.ru و wbx-content-v2.wbstatic.net، بينما تذهب الأسعار والمخزونات في طلب منفصل إلى basket-01.wb.ru ونطاقات مشابهة. لدى Ozon منطق مماثل: الواجهة الأمامية تتصل بواجهة برمجة التطبيقات الداخلية التي تجمع البيانات من الخدمات الصغيرة.

من المهم أن نفهم: استخدام مثل هذه الواجهة لا يعتبر اختراقًا رسميًا - أنت ببساطة تكرر نفس الطلبات التي يقوم بها متصفح المستخدم العادي. لكن المواقع تحمي هذه النقاط النهائية من خلال أنظمة مكافحة الروبوتات، لذا تحتاج إلى تقليد سلوك العميل الحقيقي بعناية، بما في ذلك من خلال بروكسي عالية الجودة.

كيفية العثور على واجهة برمجة التطبيقات المخفية من خلال DevTools

يمكنك العثور على واجهة برمجة التطبيقات الداخلية دون كتابة سطر واحد من الكود، باستخدام أدوات المتصفح المدمجة في Chrome أو Firefox. إليك خوارزمية خطوة بخطوة:

افتح صفحة المنتج المطلوبة في Chrome، واضغط على F12 وانتقل إلى علامة التبويب Network.
في فلتر الطلبات، اختر نوع Fetch/XHR - بهذه الطريقة ستقطع تحميل الصور، والخطوط، والستاتيك.
قم بتحديث الصفحة (F5) وانظر إلى قائمة الطلبات التي ظهرت بعد تحميل هيكل الصفحة.
ابحث عن الطلب الذي تظهر فيه في الاستجابة (علامة التبويب Response) سعر المنتج، الاسم، أو أي حقول أخرى مطلوبة بتنسيق JSON.
انقر على هذا الطلب وانسخه كـ cURL (زر الفأرة الأيمن → نسخ → نسخ كـ cURL) - سيعطيك هذا مجموعة كاملة من الرؤوس، والكوكيز، والمعلمات.
تحقق من أي المعلمات في URL إلزامية (رقم المنتج، المنطقة، إصدار واجهة برمجة التطبيقات)، وأي منها يمكن إزالته دون فقدان البيانات.

بعد ذلك، يكفي تكرار هذا الطلب من خلال مكتبة HTTP عادية، مع إدخال الرقم المطلوب أو ID المنتج بدلاً من تحميل الصفحة بالكامل. هذا يعمل لمعظم الأسواق - Wildberries، Ozon، Avito، وكذلك للعديد من المنصات الأجنبية مثل Amazon و eBay.

مقارنة حركة المرور: HTML مقابل واجهة برمجة التطبيقات JSON

الفرق في حجم البيانات كبير جدًا لدرجة أنه يستحق عرضه بالأرقام. أدناه - قياسات متوسطة لبطاقة منتج واحدة على الأسواق الشهيرة.

طريقة التحليل	متوسط حجم الاستجابة	وقت التحميل	هل يتطلب عرض JS
HTML كامل عبر Selenium	400-800 كيلوبايت	1.5-4 ثواني	نعم
طلب HTTP بسيط (requests)	150-300 كيلوبايت	0.3-0.8 ثواني	لا
واجهة برمجة التطبيقات JSON المخفية	3-15 كيلوبايت	0.1-0.3 ثواني	لا

عند مراقبة 50,000 منتج في اليوم، فإن الانتقال من متصفح بدون واجهة إلى طلبات مباشرة إلى واجهة برمجة التطبيقات يقلل حركة المرور من حوالي 30-40 جيجابايت إلى 300-700 ميجابايت في الشهر. هذا ليس فقط توفيرًا في حركة مرور البروكسي، ولكن أيضًا تقليل الحمل على البنية التحتية للخادم للمحلل - أقل من CPU للعرض، أقل من الذاكرة، أسرع في جمع البيانات.

مثال عملي بلغة بايثون

دعونا نلقي نظرة على مثال مبسط: الحصول على السعر والمخزون للمنتج من خلال طلب مباشر إلى واجهة برمجة التطبيقات الداخلية بدلاً من تحميل الصفحة الكاملة. هذه هي قالب تعليمي - يجب تحديد نقاط النهاية والمعلمات الدقيقة من خلال DevTools لموقع معين، حيث يمكن أن تختلف بنية الطلبات حسب المنطقة وإصدار واجهة برمجة التطبيقات.

import requests

def get_product_data(product_id: str, proxies: dict = None) -> dict:
    """
    يحصل على بيانات المنتج من خلال واجهة برمجة التطبيقات الداخلية بدلاً من HTML الكامل.
    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، لأن العديد من واجهات برمجة التطبيقات تتحقق من أن الطلب جاء "من المتصفح"، وليس مباشرة عبر URL. ثانيًا، نستخدم User-Agent واقعي، وليس الافتراضي من مكتبة requests، الذي يمكن اكتشافه بسهولة. ثالثًا، يتم تضمين الطلب بالكامل في استدعاء HTTP واحد دون عرض - وهذا ما يوفر فائدة كبيرة في حركة المرور والسرعة.

بالنسبة لنقاط نهاية GraphQL، فإن المنطق مشابه، ولكن بدلاً من معلمات GET، ترسل طلب POST مع جسم الطلب بتنسيق JSON، حيث تذكر الحقول المطلوبة بوضوح - وهذا يقلل أكثر من حجم الاستجابة، حيث يقوم الخادم بإرجاع البيانات المطلوبة فقط.

العمل مع البروكسي عند الطلبات إلى واجهة برمجة التطبيقات

حتى عند الانتقال إلى تنسيق JSON المضغوط، لا تزال بحاجة إلى البروكسي - تقوم الأسواق بتقييد عدد الطلبات من عنوان IP واحد وتحظر عند النشاط غير الطبيعي. يؤثر الاختيار الصحيح لنوع البروكسي هنا بشكل مباشر على استقرار المحلل.

للتجاوز الجماعي لواجهات برمجة التطبيقات للأسواق مثل Wildberries أو Ozon، تعتبر بروكسي مراكز البيانات خيارًا جيدًا - فهي توفر سرعة عالية وتكلفة منخفضة لحركة المرور، وهو أمر حاسم عند إجراء طلبات متكررة إلى نقاط نهاية JSON خفيفة الوزن. ولكن إذا كانت واجهة برمجة التطبيقات معينة محمية بنظام مكافحة الروبوتات الأكثر صرامة وتحظر الشبكات الفرعية لمراكز البيانات بالكامل، فمن الأفضل التبديل إلى بروكسي سكنية - فهي تستخدم عناوين IP حقيقية لمستخدمي المنازل وتتعرض للحظر بشكل أقل.

بالنسبة لواجهات برمجة التطبيقات التي تعتمد على تطبيقات الهواتف المحمولة (بعض إصدارات نقاط النهاية Avito أو الأسواق تقدم البيانات فقط عبر حركة مرور الهاتف المحمول)، قد يتطلب الأمر الاتصال عبر بروكسي المحمول - فهي تحاكي حركة مرور مشغلي الشبكات الخلوية الحقيقية وتنجح في الاختبارات التي تحظر عناوين IP العادية.

عند إعداد البروكسي في المحلل، من المهم أيضًا توزيع الطلبات على الوقت واستخدام تدوير IP - حتى طلب JSON المضغوط، إذا تم تكراره 1000 مرة في الدقيقة من عنوان واحد، سيثير الشك لدى نظام الحماية. قم بإعداد مجموعة من عدة جلسات بروكسي ووزع الحمل بينها، مع إضافة تأخيرات عشوائية تتراوح بين 1-3 ثوانٍ بين الطلبات.

المزالق: الرموز، التوقيعات، مكافحة الروبوتات

ليست جميع واجهات برمجة التطبيقات المخفية مفتوحة بالكامل. بعض المواقع تحمي نقاط النهاية الخاصة بها من خلال آليات إضافية يجب أخذها في الاعتبار عند بناء المحلل.

رموز الجلسة المؤقتة - تتطلب بعض واجهات برمجة التطبيقات طلبًا مسبقًا للحصول على رمز، يتم تمريره بعد ذلك في رأس الطلبات التالية ويعيش لفترة محدودة (عادةً 5-30 دقيقة).
توقيع الطلب (signature) - يتم تجزئة معلمات الطلب على العميل باستخدام مفتاح سري من كود JS في الصفحة. يجب إما إعادة إنتاج هذا التوقيع يدويًا، بعد تحليل الخوارزمية، أو تنفيذه عبر متصفح بدون واجهة فقط في مرحلة الحصول على الرمز، ثم إرسال الطلبات الخفيفة مباشرة.
تحديد معدل الطلبات حسب IP وUser-Agent - عند تجاوز معدل الطلبات، يقوم الموقع بحظر الوصول مؤقتًا. يتم حل ذلك من خلال تدوير البروكسي والتأخيرات المعقولة.
تحليل تواقيع الرؤوس - تتحقق بعض الأنظمة من مجموعة كاملة من الرؤوس (الترتيب، وجود Accept-Language، Sec-Fetch-*) وتقوم بحظر الطلبات التي تحتوي على مجموعة "غير كاملة"، والتي تكون نموذجية للسكريبتات، وليس المتصفحات.
اعتماد البيانات على الجغرافيا - يمكن أن تختلف الأسعار والمخزونات في الأسواق حسب المناطق، لذا من المهم تمرير معلمة المنطقة/المخزن الصحيحة في الطلب، وإلا ستكون البيانات غير ذات صلة.

إذا كانت واجهة برمجة التطبيقات مغلقة بتوقيع الطلب، الذي يصعب إعادة إنتاجه، فإن الخيار الوسط هو استخدام متصفح بدون واجهة (Playwright، Puppeteer) فقط لالتقاط الطلبات الشبكية واستخراج استجابة JSON الجاهزة، دون تحليل DOM. هذا أبطأ من طلب HTTP المباشر، ولكنه لا يزال أسرع وأسهل من التحليل الكامل لتنسيق الصفحة.

قائمة التحقق قبل تشغيل المحلل على واجهة برمجة التطبيقات المخفية

تم العثور على نقطة النهاية من خلال DevTools، وتم نسخها كـ cURL واختبارها في Postman أو من خلال requests.
تم تحديد المعلمات الإلزامية للطلب (ID المنتج، المنطقة، إصدار واجهة برمجة التطبيقات) واستبعاد الزوائد.
تم إعداد رؤوس User-Agent، Referer وAccept-Language بشكل واقعي.
تم التحقق مما إذا كانت هناك حاجة إلى رمز الجلسة أو توقيع الطلب، وتم التفكير في طريقة الحصول عليهما.
تم إعداد تدوير البروكسي وتأخيرات عشوائية بين الطلبات.
تم اختيار نوع البروكسي المناسب لحماية الموقع المحددة - مركز البيانات، السكنية أو المحمولة.
تم إضافة معالجة الأخطاء 429 و403 مع التبديل التلقائي إلى بروكسي آخر.
تم إعداد تسجيل حجم حركة المرور لمراقبة التوفير الفعلي.

الخاتمة

الانتقال من تحليل HTML الكامل إلى العمل مع واجهة برمجة التطبيقات المخفية ليس مجرد تحسين تقني، بل هو تقليل مباشر للنفقات على حركة مرور البروكسي والبنية التحتية. بدلاً من تحميل مئات الكيلوبايت من التعليمات البرمجية الزائدة، تحصل على JSON مضغوط يحتوي على الحقول التي تحتاجها لمراقبة الأسعار، والمخزونات أو التقييمات. بالإضافة إلى ذلك، فإن المكافأة الإضافية هي استقرار المحلل تجاه التغييرات في تنسيق الموقع، حيث تتغير واجهات برمجة التطبيقات الداخلية أقل من الواجهة الأمامية.

ومع ذلك، فإن طريقة البحث عن واجهة برمجة التطبيقات لا تلغي الحاجة إلى بروكسي عالية الجودة - أنظمة مكافحة الروبوتات في الأسواق تراقب بعناية طلبات HTML وطلبات نقاط النهاية JSON على حد سواء. إذا كنت تراقب Wildberries أو Ozon بكميات كبيرة، ابدأ ببروكسي مراكز البيانات السريعة