Limitazione della Velocità

Il rate limiting limita la frequenza con cui un client può agire — ad esempio 60 richieste al minuto per IP o per account. I server lo usano per rimanere stabili sotto carico e per attenuare tentativi di scraping e brute-force. Quando superi un limite, di solito ricevi una risposta HTTP 429 "Troppe Richieste", a volte con un'intestazione Retry-After che ti dice quanto tempo aspettare. I limiti possono essere basati sul tuo indirizzo IP, su una chiave API, su un account o su una combinazione, quindi il confine che raggiungi dipende da come il servizio ti conta.

Poiché molti limiti sono per IP, distribuire le richieste tra indirizzi è un modo comune per aumentare la capacità aggregata senza superare alcun limite singolo — un ruolo di un proxy pool nel web scraping. L'approccio etico è rispettare i limiti pubblicati, rallentare in caso di un 429 piuttosto che riprovare immediatamente, e aggiungere jitter tra le richieste in modo che il tuo modello appaia meno meccanico. s4m stesso può regolare i limiti di utilizzo in base al tipo di account, per IP e per account. Progetta il tuo client per rallentare in modo elegante; forzare attraverso un 429 di solito comporta un blocco più lungo, non dati più veloci.

s4m stesso può regolare i limiti di utilizzo attraverso il tipo di account, per IP e per account, quindi i limiti appaiono su entrambi i lati di una connessione. Nei tuoi client, progetta per un rallentamento graduale: rispetta Retry-After, aggiungi jitter tra le richieste e distribuisci il carico su un pool di proxy quando un obiettivo conta per IP. Colpire ripetutamente un 429 di solito comporta un blocco più lungo, non dati più veloci, quindi allenta, e preferisci un API ufficiale quando un sito ne offre uno.