جملهٔ «اگر API داشتید بهتر است» فقط نصف حقیقت است. بعضی APIها ناقص‌اند، بعضی فیلدها فقط در UI دیده می‌شوند، و گاهی Terms اجازهٔ ingest از endpoint پنهان را نمی‌دهد. این مقاله یک framework تصمیم می‌دهد — نه برندهٔ مطلق. تعریف API در راهنمای دریافت داده از API؛ scrape صفحه در pillar وب‌اسکرپینگ.
- API رسمی کامل → مسیر اصلی ingest.
- API ناقص → hybrid (API + scrape محدود).
- بدون API → HTML/JS با ریسک نگهداری و Terms.
معیارهای مقایسه
| معیار | API رسمی | Web Scraping |
|---|---|---|
| ساختار داده | JSON/schema و versioning | استخراج از DOM یا XHR |
| پایداری | changelog قرارداد | وابسته به layout و کلاس CSS |
| احراز هویت | API key، OAuth مستند | cookie session، mimic مرورگر |
| محدودیت درخواست | Rate limit شفاف | ضمنی + anti-bot |
| پوشش فیلد | محدود به contract | نزدیک به آنچه کاربر می‌بیند |
| داده تاریخی | بسته به endpoint و پلن | snapshotهای crawl خودتان |
| endpoint پنهان | در مستندات | XHR موبایل/فرانت — ریسک Terms |
| داده فقط در مرورگر | ممکن است در API نباشد | قابل دسترس بعد از render |
| قرارداد و دسترسی | مستندات و versioning API | ساختار صفحه و endpoint شبکه |
| نگهداری | تطبیق نسخه API | selector و wait |
| هزینه | پلن API + dev | infra مرورگر + نگهداری |
سناریو ۱: API رسمی کامل
همه فیلدهای لازم برای BI و محصول در contract هستند، Rate limit با حجم شما جور است، Terms اجازهٔ ذخیره می‌دهد → ingest از API؛ scrape را برای همان داده تکرار نکنید مگر audit UI.
سناریو ۲: API ناقص
مثال رایج: قیمت و SKU در API، badge «ارسال فوری» یا متن تبلیغ فقط در HTML. → hybrid: bulk شبانه از API؛ scrape هدفمند هفتگی یا روی subset SKU برای فیلدهای گم‌شده. هزینه نگهداری را دو برابر فرض کنید و scope scrape را محدود نگه دارید.
سناریو ۳: بدون API عمومی
فقط وب اپ: یا Playwright برای DOM، یا همان JSON که فرانت fetch می‌زند — با بودجه نگهداری و ریسک بلاک در معماری. reverse engineering endpoint پایدارتر از scrape کامل HTML است اما وابستگی به تغییر API داخلی دارد.
Decision framework
- دسترسی پایدار به API و/یا crawl از نظر فنی و قرارداد پروژه تأیید شده؟
- آیا هر فیلد اجباری خروجی در API موجود است؟
- تأخیر و Rate limit API با SLA شما سازگار است؟
- هزینهٔ سالانه نگهداری scrape (انسان + infra) در برابر پلن API چقدر است؟
- آیا «حقیقت محصول» در UI با API یکی است یا marketing فقط در صفحه است؟
قبل از scrape کل سایت، DevTools → Network را برای لیست محصول چک کنید؛ گاهی endpoint JSON پایدارتر از HTML است — اگر در محدوده پروژه و پایدار باشد، مسیر اصلی ingest می‌شود.
اشتباهات رایج
فرض پوشش ۱۰۰٪ API وقتی تیم محصول فیلد جدید فقط در UI می‌گذارد؛ scrape کامل به‌خاطر lazy بودن از خواندن مستندات API؛ نادیده گرفتن historical data که API نمی‌دهد ولی شما باید archive کنید.
بعد از ingest، نرمال‌سازی برای هر دو مسیر یکسان است. خطا و Rate limit: مدیریت خطا.
در عمل چه انتخابی کنیم؟
اگر پاسخ سؤال ۲ برای API «بله» برای همه فیلدهای حیاتی → API مسیر اصلی. اگر یک فیلد حیاتی فقط در UI → hybrid با scope محدود. اگر API نیست → scrape/Playwright با بودجه نگهداری واقع‌بینانه. پیاده‌سازی: توسعه API و Scraper اختصاصی.