تفاوت اسکرپ و API؛ کی قرارداد رسمی کافی است و کی استخراج صفحه

اگر دنبال تفاوت اسکرپ و API هستید، مسئله فنیِ «کدام کتابخانه را نصب کنیم» نیست. مسئله این است داده را از کدام قرارداد می‌گیرید: از درگاهی که صاحب منبع برای تبادل ساخته، یا از همان صفحه‌ای که مرورگر انسان می‌بیند. API فیلد، نرخ و نسخه را اعلام می‌کند. اسکرپ ظاهر HTML را می‌خواند و تا وقتی ساختار صفحه عوض نشده کار می‌کند. یکی همیشه بهتر نیست؛ انتخاب غلط یا داده ناقص می‌دهد یا نگهداری را گران می‌کند.

جست‌وجوهایی مثل «تفاوت اسکرپ و API»، «کی API کافی است»، «کی اسکرپ لازم می‌شود»، «پایداری داده» و «خروجی CSV و JSON» معمولاً از تیمی می‌آید که می‌خواهد کاتالوگ، قیمت یا فهرست عمومی بسازد و نمی‌داند از کجا شروع کند. در این راهنما قرارداد دسترسی، نشانه‌های کافی‌بودن API، موقعیت استخراج صفحه، شکنندگی سلکتور، قالب تحویل و مسیر ترکیبی را جدا می‌کنیم. تعریف استخراج در راهنمای اسکرپ دیتا آمده است، مفهوم قرارداد در مقاله API چیست، و مرز مجاز در متن قانونی بودن وب اسکرپینگ. اجرای پروژه‌های مجاز در خدمت اسکرپ داده روبینش تعریف می‌شود.

Fetching data from an API allows you to retrieve structured information from a server using a documented request, rather than scraping it out of a page meant for people.

اسکرپ و API چه فرقی در دسترسی به داده دارند؟

API یک قرارداد است: آدرس، روش درخواست، احراز هویت، محدودیت نرخ، شکل پاسخ و اعلام نسخه‌ها. شما فیلدی را می‌خواهید که ارائه‌دهنده تصمیم گرفته در اختیار بگذارد. اگر فیلد در قرارداد نباشد، در پاسخ هم نیست؛ حتی اگر همان مقدار روی صفحه محصول دیده شود. این محدودیت گاهی آزاردهنده است، اما مزیتش این است که تغییر ظاهر سایت لزوماً قرارداد را نمی‌شکند. تیم مقصد معمولاً نسخه را اعلام می‌کند و فرصت مهاجرت می‌دهد.

اسکرپ برعکس رفتار می‌کند. داده را از HTML، ویژگی‌های عنصر، اسکریپت جاسازی‌شده یا همان چیزی که بعد از رندر در مرورگر دیده می‌شود برمی‌دارد. پوشش می‌تواند وسیع‌تر باشد، چون هرچه روی صفحه عمومی باشد بالقوه قابل خواندن است. هزینه این پوشش، وابستگی به ظاهر است. تغییر کلاس، ترتیب بلوک‌ها یا بارگذاری تنبل می‌تواند ستون قیمت را خالی یا غلط کند. نگهداری اسکرپ یعنی پایش شکست، نه فقط نوشتن یک اسکریپت اول.

از نظر کسب‌وکار، تفاوت اسکرپ و API در «آزادی در برابر تعهد» خلاصه می‌شود. API شما را به محدوده ارائه‌دهنده متعهد می‌کند و در عوض پایداری نسبی می‌دهد. اسکرپ شما را به آنچه صفحه نشان می‌دهد نزدیک می‌کند و در عوض تعمیر مداوم می‌خواهد. اگر تصمیم قیمت‌گذاری یا موجودی به این داده وصل است، پایداری معمولاً مهم‌تر از گرفتن یک فیلد اضافه است که هفته بعد از بین می‌رود.

کی API کافی است؟

API وقتی کافی است که سه شرط با هم برقرار باشد. اول، فیلدهای لازم برای تصمیم واقعاً در پاسخ وجود داشته باشند؛ نه اینکه «تقریباً همان» را حدس بزنید. دوم، تازگی داده با کاربرد بخواند: اگر موجودی هر ساعت عوض می‌شود و API هر شب به‌روز می‌شود، قرارداد از نظر فنی هست ولی از نظر کسب‌وکار کافی نیست. سوم، سهمیه، احراز هویت و هزینه پلن با حجم پروژه جور باشد. پلن رایگان آزمایش است، نه خوراک تولید.

نشانهٔ دیگر کافی‌بودن، مستند بودن خطاهاست. اگر ۴۲۹، ۴۰۱ و فیلد خالی معنای مشخص دارند، می‌توانید صف، تلاش مجدد و هشدار بسازید. اسکرپ در همین موقعیت ممکن است صفحهٔ ورود، captcha یا HTML ناقص برگرداند و اسکریپت آن را «قیمت صفر» بفهمد. برای اتصال پایدار بین سیستم‌ها، مسیر اول تقریباً همیشه قرارداد رسمی است؛ اسکرپ را برای مشاهدهٔ ویترین بگذارید نه برای هستهٔ سفارش.

گاهی API هست ولی ناقص است. مثلاً فهرست کالا را می‌دهد و موجودی لحظه‌ای را نمی‌دهد، یا فقط برای شریک تجاری باز است. اینجا «کافی نیست» با «وجود ندارد» فرق دارد. وجودنداشتن ممکن است اسکرپ محدود صفحهٔ عمومی را مطرح کند. ناقص‌بودن ممکن است مذاکره برای پلن بالاتر، مجوز کتبی یا ترکیب دو منبع را ایجاب کند. پریدن مستقیم به اسکرپ چون «سریع‌تر به نظر می‌رسد» معمولاً بدهی نگهداری می‌سازد.

کی اسکرپ لازم می‌شود؟

اسکرپ وقتی مطرح می‌شود که داده روی صفحهٔ عمومی دیده می‌شود، کانال رسمی وجود ندارد یا فیلد حیاتی در API نیست، و برداشت بدون شکستن ورود و قفل ممکن است. نمونهٔ رایج، پایش قیمت نمایشی چند فروشگاه است که خوراک شریک نمی‌دهند. حتی اینجا هم اول robots.txt، شرایط استفاده و نوع داده را ببینید. صفحهٔ باز به‌معنی اجازهٔ انبوه نیست.

موقعیت دوم، دادهٔ تکمیلی است که API تعمداً حذف کرده: برچسب پروموشن روی کارت کالا، ترتیب نمایش در دسته، یا متنی که فقط در قالب ویترین معنا دارد. اگر هدف تحلیل بازار است نه ساخت آینهٔ محتوایی رقیب، این فیلدها ممکن است ارزش داشته باشند. اگر هدف کپی شرح و عکس برای فروشگاه خودتان است، مسئله از انتخاب ابزار خارج و وارد حق نشر می‌شود.

موقعیت سوم، چندمنبعی است. API یک تأمین‌کننده را پوشش می‌دهد و بقیه فقط سایت دارند. تیم‌ها گاهی همه را اسکرپ می‌کنند تا یکدست شود. راه بالغ‌تر این است منبع دارای قرارداد را از API بگیرید و فقط منابع بدون کانال را، با نرخ محترمانه و فیلد حداقل، از صفحه بخوانید. یکسان‌سازی شناسهٔ کالا بعد از جمع‌آوری سخت‌تر از انتخاب منبع است؛ تطبیق را از روز اول طراحی کنید.

این مقاله روش دورزدن ورود، captcha یا مسدودسازی را آموزش نمی‌دهد. اگر برای رسیدن به داده باید قفل را شکست، آن داده برای این مسیر تعریف نشده است. جایگزین، مجوز، خوراک یا حذف آن منبع از محدوده است. پایش قیمت رقبا همین کاربرد را با تمرکز تصمیم خرید توضیح می‌دهد، نه با تکنیک تهاجمی.

پایداری داده و شکست سلکتور

پایداری یعنی فردا همان فیلد، با همان معنی، سر وقت برسد. در API، شکست معمولاً واضح است: کد وضعیت، بدنهٔ خطا، یا اعلان deprecate. در اسکرپ، شکست می‌تواند خاموش باشد. صفحه ۲۰۰ برمی‌گردد، ولی بلوک قیمت به بنر تبلیغاتی تبدیل شده و اسکریپت عدد اشتباه می‌نویسد. برای تصمیم موجودی، دادهٔ غلط از دادهٔ غایب خطرناک‌تر است چون گزارش «همه‌چیز خوب است» می‌سازد.

برای کاهش این ریسک، اسکرپ تولید باید سه لایه کنترل داشته باشد. لایهٔ ساختار: اگر تعداد کارت کالا در دسته ناگهان صفر شد، اجرا بایستد. لایهٔ نوع: قیمت باید عدد باشد، واحد پول مشخص باشد، URL معتبر باشد. لایهٔ نمونه: هر اجرا چند رکورد را با مشاهدهٔ دستی همان صفحه مقایسه کند. بدون این لایه‌ها، «ربات هر شب اجرا می‌شود» حس پایداری می‌دهد و در عمل بدهی پنهان است.

تغییر صفحه بخشی از عمر وب است، نه حادثه. فروشگاه قالب عوض می‌کند، رویداد فصلی می‌گذارد، یا محتوا را سمت کلاینت می‌راند. وقتی HTML خام خالی است و داده فقط در DOM بعد از جاوااسکریپت است، مسیر رندر را در اسکرپ با Playwright ببینید نه به‌عنوان میانبر قفل. اسکرپری که فقط به یک کلاس CSS چسبیده، اولین بازطراحی را نمی‌بیند. اگر پروژه باید ماه‌ها زنده بماند، هزینهٔ پایش را در برآورد بیاورید. اگر بودجه فقط برای اسکریپت اول است، شاید API ناقص با فیلد کمتر، انتخاب صادقانه‌تری باشد.

خروجی CSV و JSON را چطور انتخاب کنیم؟

قالب خروجی از روش جمع‌آوری جداست. API معمولاً JSON می‌دهد؛ اسکرپ اغلب HTML را به جدول تبدیل می‌کند. مصرف‌کننده باید تصمیم بگیرد کدام فایل را می‌خواهد. CSV برای تحلیل در صفحه گسترده، فیلتر فروش و پیوست ایمیل داخلی مناسب است. هر سطر یک رکورد است و ستون‌ها باید پایدار نام‌گذاری شوند. قبل از تحویل، رمزگذاری فارسی، جداکننده و اعشار را با فایل نمونه در Excel تست کنید.

JSON وقتی لازم است که ساختار تو در تو دارید: چند تصویر، چند تنوع قیمت، چند فروشنده روی یک کالا. فشردن این داده در یک سلول CSV یا تکرار سطرها را شلوغ می‌کند یا اطلاعات را می‌ریزد. اگر سامانهٔ شما بعداً همان داده را به پنل یا اپ می‌دهد، JSON نزدیک‌تر به قرارداد API داخلی است. گاهی هر دو را با یک زمان برداشت مشترک تحویل می‌دهیم تا تحلیلگر و برنامه‌نویس هر کدام مسیر خود را داشته باشند.

نام فیلد را از روز نمونه قفل کنید. «price» با «price_display» و «price_final» یکی نیستند. تخفیف خط‌خورده، مالیات و هزینه ارسال اگر در تصمیم اثر دارند باید ستون جدا باشند. زمان برداشت را همیشه نگه دارید؛ عدد بدون زمان برای مقایسهٔ رقبا بی‌معنی است. شناسهٔ پایدار کالا را اگر منبع ندارد، از ترکیب منبع و URL بسازید و قاعده را مستند کنید تا اجرای بعدی رکوردها را عوض نکند.

مسیر ترکیبی: قرارداد به‌علاوه مشاهدهٔ صفحه

بسیاری از پروژه‌های بالغ دو لایه دارند. لایهٔ هویت و موجودی از API یا خوراک تأمین‌کننده می‌آید. لایهٔ مشاهده — رتبه در دسته، برچسب کمپین، قیمت ویترین — از صفحهٔ عمومی با نرخ پایین خوانده می‌شود. این ترکیب پوشش را بالا می‌برد بدون اینکه هستهٔ داده را به سلکتور CSS وابسته کند. شرط موفقیت، کلید مشترک است: اگر نتوانید ردیف API را به کارت صفحه وصل کنید، دو مجموعهٔ موازی دارید نه یک منبع حقیقت.

ترکیب را با اسکرپ همه‌چیز از همه جا عوض نکنید. هر منبع اضافه، ToS جدا، شکست جدا و هزینهٔ تطبیق جدا دارد. محدوده را از سؤال کسب‌وکار ببرید: کدام تصمیم، با کدام فیلد، از کدام منبع. اگر سؤال «قیمت نمایشی سه رقیب مشخص» است، سه منبع کافی است. اگر سؤال «کل بازار» است، ابتدا تعریف بازار را بنویسید وگرنه پروژه تمام نمی‌شود.

نرخ درخواست را در هر دو مسیر جدی بگیرید. API سهمیه را در مستند می‌نویسد؛ رد شدن از آن معمولاً قطع سرویس است نه زرنگی. اسکرپ سهمیهٔ اعلام‌شده ندارد، اما ظرفیت سرور مقصد و حسن‌نیت را دارد. فاصلهٔ محترمانه بین درخواست‌ها، شناسایی شفاف ربات و ایستادن بعد از خطا، بخشی از کیفیت پروژه است. فشردن منبع برای «تمام شدن تا فردا» هم داده را خراب می‌کند هم مسیر مسئولانه را می‌بندد. حجم را با نمونه و زمان واقعی بسنجید، نه با آرزوی پوشش نامحدود.

اشتباهات رایج در انتخاب مسیر داده

• اسکرپ را اول انتخاب کردن چون «API سخت به نظر می‌رسد»
• فرض اینکه JSON یعنی داده تمیز است و اعتبارسنجی لازم نیست
• یکی‌دانستن فیلد صفحه با فیلد قرارداد بدون تطبیق معنی
• نادیده‌گرفتن سهمیه و بعد تعجب از قطع سرویس
• ساختن کاتالوگ فروش از محتوای دارای حق نشر رقیب
• نداشتن طرح تعمیر وقتی سلکتور می‌شکند

چک‌لیست انتخاب اسکرپ یا API

1. تصمیم کسب‌وکار و حداقل فیلد لازم نوشته شده است.
2. وجود API، پلن، تازگی و پوشش فیلد بررسی شده است.
3. اگر API کافی است، اسکرپ وارد محدودهٔ تولید نمی‌شود.
4. اگر اسکرپ مطرح است، robots، ToS و نوع داده چک شده‌اند.
5. دورزدن ورود و قفل خارج از محدوده است.
6. قالب تحویل CSV یا JSON با مصرف‌کننده هماهنگ شده است.
7. کنترل شکست خاموش و زمان برداشت در طرح هست.
8. مالکیت استفاده داخلی در برابر بازنشر روشن است.

جمع‌بندی: اول قرارداد، بعد صفحه

تفاوت اسکرپ و API در ابزار نیست؛ در محل حقیقت داده است. API وقتی فیلد، تازگی و سهمیه را می‌دهد مسیر پیش‌فرض تولید است. اسکرپ وقتی صفحهٔ عمومی چیزی را نشان می‌دهد که قرارداد ندارد، با نگهداری و محدودیت حقوقی معنا پیدا می‌کند. پایداری را جدی بگیرید، خروجی را از روی مصرف انتخاب کنید و محدوده را کوچک نگه دارید.

برای بررسی منبع، فیلد و روش مجاز، از صفحه اسکرپ داده یا تماس با روبینش شروع کنید. اگر هنوز بین کرال و استخراج مردد هستید، تفاوت کرالر و اسکرپر را هم ببینید.