Limitation de débit

La limitation de taux restreint la fréquence à laquelle un client peut agir — par exemple, 60 requêtes par minute par IP ou par compte. Les serveurs l'utilisent pour rester stables sous charge et pour atténuer les tentatives de scraping et de force brute. Lorsque vous dépassez une limite, vous recevez généralement une réponse HTTP 429 "Trop de requêtes" , parfois avec un en-tête Retry-After vous indiquant combien de temps attendre. Les limites peuvent être basées sur votre adresse IP, une clé API, un compte ou une combinaison, donc la limite que vous atteignez dépend de la façon dont le service vous compte.

Parce que de nombreuses limites sont par IP, distribuer les requêtes entre les adresses est un moyen courant d'augmenter le débit global sans dépasser une limite unique — un rôle d'un proxy pool dans l'extraction de données sur le web. L'approche éthique consiste à respecter les limites publiées, à se retirer en cas de 429 plutôt que de réessayer immédiatement, et à ajouter du jitter entre les requêtes afin que votre modèle semble moins mécanique. s4m lui-même peut ajuster les limites d'utilisation selon le type de compte, par IP et par compte. Concevez votre client pour ralentir de manière élégante ; forcer à travers un 429 entraîne généralement un blocage plus long, pas des données plus rapides.

s4m lui-même peut ajuster les limites d'utilisation selon le type de compte, par IP et par compte, de sorte que les limites apparaissent des deux côtés d'une connexion. Dans vos propres clients, concevez pour un ralentissement gracieux : respectez Retry-After, ajoutez jitter entre les requêtes, et répartissez la charge sur un pool de proxy lorsque la cible compte par IP. Insister à travers un 429 entraîne généralement un blocage plus long, pas des données plus rapides, donc reculez, et préférez un API officiel lorsqu'un site en propose un.