← العودة إلى المدونة

واجهة JSON API المخفية للموقع: كيفية العثور على نقاط النهاية الداخلية وتقليل حركة مرور المتصفح

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

📅١١ ربيع الآخر ١٤٤٨ هـ
واجهة JSON API المخفية للموقع: كيفية العثور على نقاط النهاية الداخلية وتقليل حركة مرور المتصفح

يستخرج المحلل 400 كيلوبايت من HTML من أجل ثمانية حقول، والتي يقدمها الموقع لنفسه في استجابة JSON بحجم 8 كيلوبايت. الفرق بمقدار خمسين مرة - ليس عن "كود جميل"، بل عن فاتورة البروكسي السكني، حيث تدفع مقابل كل جيجابايت. دعونا نحلل كيف نجد API الداخلي للموقع، وما الذي يمنع تكراره في عام 2026، ومتى يجب التخلي عن هذه الفكرة.

لماذا تبحث عن API مخفي، إذا كان HTML يتم تحليله بالفعل

تقريبًا أي واجهة حديثة - React، Vue، Angular، Next.js - تقوم أولاً بتحميل هيكل الصفحة، ثم تسحب البيانات من خلال طلبات منفصلة إلى نقاط النهاية الخاصة بها. هذه النقاط غير موثقة، لكنها موجودة، وتستجيب بـ JSON نقي ومتاحة بدون متصفح بدون رأس.

ما تحصل عليه عند الانتقال إليها:

  • ينخفض ​​حجم المرور بشكل كبير. عند تحليل عرض منتج نموذجي، تزن صفحة HTML حوالي 400 كيلوبايت مع التنسيق، الأنماط، والمتعقبين، بينما نقطة النهاية JSON المقابلة تزن حوالي 8 كيلوبايت، مع وجود حقول أكثر فيها: معرفات داخلية، مخزونات، خيارات المنتج.
  • لا حاجة لمتصفح. يتم التخلص من معالجة JavaScript، وبالتالي - الذاكرة، المعالج، وعشرات الطلبات الإضافية للخطوط والتحليلات.
  • البيانات منظمة بالفعل. لا توجد محددات تتعطل عند تغيير فئة CSS.
  • طلبات أقل - فرص أقل للحظر. رسم صفحة كتالوج واحدة في المتصفح يعني عشرات الطلبات إلى الموقع؛ نفس كمية البيانات عبر API - واحدة فقط.

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

خطوة بخطوة: كيفية العثور على نقطة النهاية

  1. أولاً تحقق مما إذا كان هناك API رسمي. تحقق من /developers، /api، /docs للموقع المستهدف. API موثق علنيًا يتم إصداره ويقوم بتحذيرك بشأن الإصدارات القديمة - بينما يتغير الخاص به بهدوء.
  2. افتح أدوات المطورين (F12) وانتقل إلى علامة الشبكة، مع التأكد من أن التسجيل مفعل.
  3. قم بتفعيل فلتر Fetch/XHR. يقوم هذا بقطع الصور، الخطوط، والتحليلات، تاركًا فقط الطلبات للحصول على البيانات.
  4. قم بتنظيف القائمة لإزالة ضوضاء التحميل الأولي.
  5. استفز البيانات المطلوبة: قم بالتمرير عبر النتائج، اضغط على "الصفحة التالية"، طبق الفلتر، افتح بطاقة. سيظهر الطلب الذي يهمك في لحظة الفعل.
  6. ابحث عن الاستجابة التي تحتوي على بياناتك. أسرع طريقة - Ctrl+F في لوحة الشبكة: ابحث عن قيمة فريدة تراها على الشاشة (رقم المقال، السعر الدقيق، جزء من الاسم)، وانظر أي طلب أنشأها.
  7. انسخ الطلب بالكامل: انقر بزر الماوس الأيمن على السطر → نسخ → نسخ كـ cURL. بعد ذلك، قم بتحويله إلى كود عبر curlconverter - حتى لا تفقد أي رأس.

طرق نموذجية يجب النظر إليها أولاً: /api/، /v1/، /v2/، /search، /products، /listings، /graphql.

حالة خاصة: المواقع على Next.js

هنا، غالبًا ما لا تتطلب البيانات طلبًا منفصلًا على الإطلاق - فهي موجودة مباشرة في HTML. في Pages Router القديم، يكون هذا الكتلة __NEXT_DATA__. في App Router (Next.js 13 وما بعده)، يتم توزيع البيانات للتجديد عبر استدعاءات self.__next_f.push() في عدة عقد نصية - هذه هي الحمولة المسلسلة لمكونات خادم React. من غير المريح تحليلها يدويًا: تشير الكتل إلى بعضها البعض عبر بادئات $ ويمكن أن يتم قطعها في منتصف السطر. هناك مكتبة لـ Python nextflight، التي تقوم بتحليل كل من الحمولة Flight من HTML، واستجابة RSC الخام (طلب مع رأس RSC: 1)، وتقترح البحث فيها حسب أسماء المفاتيح، وليس حسب مؤشرات المصفوفة - هكذا يتحمل المحلل إعادة نشر الموقع.

عكس المعلمات: الترقيم والفلاتر

نقطة النهاية التي تم العثور عليها عادة ما تكون معلمة. هناك ثلاث مخططات:

  • حسب الصفحات: ?page=3&per_page=20
  • الإزاحة والحد: ?offset=40&limit=20
  • المؤشر: ?after=<token>&limit=20 - يأتي رمز الصفحة التالية في جسم الاستجابة السابقة

ثلاث قواعد توفر ساعات من التصحيح:

  • توقف عند حزمة فارغة، وليس عند عدد الصفحات المحسوب مسبقًا: غالبًا ما يكذب العداد total في APIs الخاصة أكثر مما ترغب.
  • تحقق من الحجم الفعلي للحزمة. طلبت 100، وصلت 20 - يعني أن نقطة النهاية لديها حدها الخاص، وأن حساباتك للصفحات غير صحيحة بالفعل.
  • لا تدخل الصفحة 500. يتم قطع الترقيم العميق تقريبًا في كل مكان بواسطة الخادم؛ بدلاً من ذلك، قم بتقطيع العينة باستخدام الفلاتر - حسب الفئة، حسب نطاق الأسعار، حسب التاريخ.

لماذا يعمل cURL من المتصفح، بينما لا يعمل كودك

هذه هي النقطة الأكثر شيوعًا للفشل، والسبب غالبًا ما يكون واحدًا: فقدان رأس. يحمل cURL المنسوخ كل سياق الطلب، بينما العميل المكتوب يدويًا - لا.

ما يظهر عادة أنه ضروري:

  • رؤوس مخصصة مع بادئة X- - X-CSRF-Token، X-Requested-With: XMLHttpRequest وجميع أنواع X-*-Token التي يدرجها الواجهة الأمامية بنفسه. بدونها، ستحصل على استجابة في نطاق 400–500.
  • Referer - رأس سياقي يتم إنشاؤه بواسطة إجراء المستخدم. تتحقق العديد من نقاط النهاية من أن الطلب "جاء من صفحته الخاصة".
  • Authorization: Bearer <JWT> - رمز قصير العمر، عادة ما يكون لمدة 15–60 دقيقة. من غير المجدي تشفيره: يجب أن تكون قادرًا على الحصول على رمز جديد.
  • ملفات تعريف الارتباط الجلسية - احتفظ بها في كائن الجلسة، ولا تنسخها يدويًا.
  • نوع المحتوى الصحيح Content-Type لـ POST: application/json و application/x-www-form-urlencoded ترمز الجسم بطرق مختلفة، وعدم المطابقة مع النوع المعلن يكسر الطلب بهدوء.

أين تبحث عن الرموز نفسها، إذا لم تكن في ملفات تعريف الارتباط: في مصدر HTML داخل <script> (البحث عن قيمة معروفة عبر Ctrl+F)، في حزم JavaScript، في localStorage أو IndexedDB - علامة التبويب التطبيق في أدوات المطورين.

المزالق التي يتم اكتشافها متأخرًا

API الخاص يتغير بدون تحذير. ليس لديه إصدار، ووعود بالتوافق والدعم: يقوم فريق الواجهة الأمامية بإعادة تسمية الحقل مساء الخميس، ويجمع المحلل فراغًا. الحماية ليست "محدد موثوق"، بل التحكم في الهيكل: تحقق من أن الحقول الإلزامية في مكانها ونوعها المطلوب؛ راقب نسبة القيم الفارغة وعدد السجلات في التشغيل؛ تخطى السجلات التالفة، لكن ارفع الإنذار إذا تجاوز العطل 10٪؛ احتفظ بالاستجابات الخام، حتى يكون لديك ما تقارنه لاحقًا.

أحيانًا يكون API محميًا بشكل أقوى من الصفحة. يحدث بانتظام: يتم تسليم HTML بهدوء، بينما على /api/ يوجد مضاد للبوت يتحقق من كل من بصمة TLS، ومجموعة الرؤوس. عندها، تتحول توفير حركة المرور إلى زيادة في نسبة الطلبات غير الناجحة، ويؤكل الربح.

الطلبات الموقعة. إذا كان في المعلمات شيء مثل sign، hash أو _s، يعتبر الواجهة الأمامية التوقيع في JavaScript. إعادة إنتاجه هو مشروع منفصل، وغالبًا ما يكون من الأرخص البقاء على HTML.

قيود التردد. نقاط النهاية الخاصة ليست مصممة للتدفق: احتفظ بـ 1–2 طلبات في الثانية، ضع مهلات منفصلة على الاتصال والقراءة (على سبيل المثال، 5 و30 ثانية)، كرر فقط الأخطاء العابرة - 429، 500، 502، 503، 504 - ولا تلمس 401 و404. التأخير الأسي مع التذبذب إلزامي، وإلا ستذهب جميع العمال إلى الجولة الثانية في نفس الوقت. لمزيد من التفاصيل - في تحليل مهلات ومنطق إعادة المحاولة للبروكسي.

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

متى تبقى على HTML

API المخفي ليس دائمًا فوزًا. ابق على تحليل الصفحات إذا:

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

ما نوع البروكسي الذي يجب استخدامه لتحليل API

الانتقال إلى JSON يغير الحساب، لأن نقطة الاختناق تتحرك: يصبح حجم المرور قليلًا، بينما تزداد المتطلبات لجودة IP واستقرار الجلسة.

  • نقطة نهاية مفتوحة بدون مصادقة وبدون مضاد للبوت. هنا يكفي بروكسي مركز البيانات: حجم البيانات صغير، ولا داعي للدفع مقابل السكني.
  • نقطة نهاية خلف مضاد للبوت أو مرتبطة بالجلسة. تحتاج إلى بروكسي سكني مع جلسة لاصقة: يجب أن يتطابق الرمز، وملفات تعريف الارتباط وIP طوال سلسلة الطلبات، وإلا سيقوم الخادم بإسقاط الجلسة في الطلب الثاني. في نفس الوقت، ستبقى الفاتورة متواضعة - يتم استهلاك الجيجابايت في وضع JSON ببطء.
  • البيانات من تطبيق الهاتف المحمول. إذا كانت النسخة الويب مغلقة، وكان التطبيق يقدم نفس الشيء بشكل أسهل، يتم البحث عن النقاط النهائية من خلال اعتراض المرور - هذه عملية منفصلة، تم تحليلها في المقالة حول البحث عن API المخفي لتطبيق الهاتف المحمول عبر mitmproxy.

باختصار

عشرون دقيقة في أدوات المطورين غالبًا ما تحل محل أيام من الصراع مع المتصفح بدون رأس: فلتر Fetch/XHR، البحث عن قيمة مرئية، نسخ كـ cURL - والآن لديك طلب يعمل. بعد ذلك، يتم حل التفاصيل: نقل جميع الرؤوس، تحليل مخطط الترقيم، وضع التحقق من الاستجابة وتقييم بموضوعية ما إذا كانت نقطة النهاية محمية بشكل أقوى من الصفحة نفسها. حيث يعمل API الخاص، فإنه يقلل من حجم المرور وعدد الطلبات - مما يعني فورًا تكلفة البروكسي واحتمالية الحظر.