اگر Web Scraping می‌کنید این کارها را انجام ندهید

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

کوکی و نشست را hard-code نکنید

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

تعداد درخواست را کنترل کنید

وجود حلقه به‌تنهایی DDoS نیست؛ مسئله حجم، هم‌زمانی و اثر بار روی سرویس است. محدودیت اعلام‌شده را رعایت کنید و تعداد تلاش مجدد را محدود نگه دارید. تأخیر تصادفی تضمین نمی‌کند که درخواست‌ها مجاز باشند یا مسدود نشوند.

import time
import requests

urls = ["https://example.com/page-1", "https://example.com/page-2"]

with requests.Session() as session:
    for url in urls:
        try:
            response = session.get(url, timeout=(5, 20))
            if response.status_code in (403, 429):
                print("Access denied or rate limited; stop and review.")
                break
            response.raise_for_status()
            # Parse only the data needed for your task.
        except requests.RequestException as error:
            print(type(error).__name__)
        time.sleep(2)

این کد نمونهٔ ساختار کنترل خطاست و HTML را استخراج نمی‌کند. فاصلهٔ دو ثانیه نرخ مجاز عمومی برای سایت‌ها نیست؛ مقدار واقعی باید با شرایط سرویس هماهنگ باشد. پاسخ 429 و هدر Retry-After را در طراحی retry در نظر بگیرید.

هم‌زمانی را بی‌حساب زیاد نکنید

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

تغییر HTML را انتظار داشته باشید

انتخابگرهای صفحه را جدا از منطق ذخیره‌سازی نگه دارید و خروجی مورد انتظار را با دادهٔ نمونه کنترل کنید. خالی‌شدن نتیجه می‌تواند نشانهٔ تغییر ساختار باشد، نه نبود داده. هرجا API رسمیِ متناسب وجود دارد، مستندات آن را بررسی کنید. تغییر User-Agent یا ترتیب درخواست‌ها مشکل قرارداد داده و مجوز دسترسی را حل نمی‌کند.

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

مرجع: مستندات رسمی؛ نسخهٔ مستندات را با نسخهٔ پروژهٔ خود تطبیق دهید.