POST https://api.acedata.cloud/webextrator/render
واجهة برمجة تطبيقات عرض صفحات الويب WebExtrator هي خدمة عرض صفحات ويب تعتمد على Chromium بدون رأس. عند إعطائها عنوان URL، تعيد HTML مكتمل العرض (بما في ذلك المحتوى الذي تم حقنه بواسطة JS)، نص عادي، عنوان الصفحة، والعنوان URL النهائي.
Render هو واجهة WebExtrator الأساسية. إذا كنت بحاجة إلى نتائج استخراج منظمة (نص المقال، أسعار المنتجات، مكونات الوصفات …)، يرجى استخدام
/webextrator/extract — حيث يتم تشغيل مجموعة كاملة من خطوط استخراج نوعية على نفس أساس العرض.
عملية التقديم
لاستخدام صفحة خدمة WebExtrator، يجب أولاً الذهاب إلى لوحة تحكم Ace Data Cloud للحصول على رمز API الخاص بك، احتفظ به للاستخدام لاحقًا.
إذا لم تكن قد قمت بتسجيل الدخول أو التسجيل، سيتم تحويلك تلقائيًا إلى صفحة تسجيل الدخول لدعوتك للتسجيل وتسجيل الدخول، وبعد الانتهاء، سيتم إرجاعك تلقائيًا إلى الصفحة الحالية.
يمكن استخدام رمز API واحد لاستدعاء جميع خدمات المنصة، دون الحاجة لتقديم طلب لكل خدمة على حدة. ستمنحك أول مرة طلب مجانية، يمكنك تجربتها مجانًا؛ عند نفاد الرصيد، يمكنك إعادة شحن الرصيد العام في لوحة التحكم.
📘 الوثائق الكاملة: صفحة خدمة WebExtrator →
المصادقة
تستخدم جميع واجهات WebExtrator مصادقة Bearer Token القياسية:معلمات الطلب
تستخدم عقود المنصة snake_case بشكل موحد. تدعم خدمات العرض الداخلية camelCase، لكن جميع الاستدعاءات الخارجية تستخدم snake_case.
هيكل ملفات تعريف الارتباط
الاستجابة المتزامنة
الاستجابة غير المتزامنة
عندasync=true (أو تقديم callback_url) يتم إرجاعها على الفور (HTTP 200):
POST إلى callback_url (إذا تم تكوينه)، أو من خلال
/webextrator/tasks للاستعلام النشط.
هيكل الاسترجاع
تقوم المنصة بإرسالPOST بنفس envelope تمامًا كما في الوضع المتزامن إلى callback_url،
Content-Type: application/json. تعتبر أي استجابة 2xx تأكيدًا؛ بينما 5xx ستخضع لإعادة المحاولة مع تراجع أسي لمدة حوالي 5 دقائق.
استجابة الخطأ
هيكل الخطأ:
مثال
cURL
بايثون (requests)
Node.js (fetch)
غير متزامن + رد الاتصال
{ "success": true, "task_id": "...", "trace_id": "...", "started_at": 1777717800.123 }؛
عند اكتمال المهمة، ستقوم المنصة بإرسال POST بالنتيجة الكاملة إلى callback_url الخاص بك.
تجاوز التخزين المؤقت بالقوة
نصائح ومشاكل
- اختيار
wait_untilمهم جدًا.networkidleهو الأكثر استقرارًا ولكنه الأبطأ؛domcontentloadedسريع ولكنه قد يفوت المحتوى المحقون بشكل غير متزامن؛loadمناسب للصفحات الثابتة التقليدية. - تجاهل مفتاح التخزين المؤقت لـ
async. طلبات المتزامنة وغير المتزامنة لنفس URL تضرب نفس إدخال التخزين المؤقت، التبديل بحرية لن يؤدي إلى الفشل. - تجاهل مفتاح التخزين المؤقت لـ
bypass_cacheوcache_ttl_seconds. هذان مفتاحان للتشغيل، لا يؤثران على محتوى الاستجابة. - تخزين
cookiesوheadersسيؤدي إلى تقسيم التخزين المؤقت. تخصيص هذين سيجعل أول مجموعة متطابقة تفشل. - تجاوز SPA غالبًا ما يتجاوز 30 ثانية الافتراضية. يُنصح بـ
timeout: 60،wait_until: "domcontentloaded"،delay: 4، مع استخدامwait_for_selectorلانتظار العناصر التي تهمك حقًا. block_resourcesهو أسرع طريق لتقليل التأخير. تم حظر الصور / الخطوط / الوسائط بشكل افتراضي؛ إذا كنت تستخرج دون الاعتماد على تخطيط CSS، يمكنك إضافةstylesheetلتكون أسرع.

