Limiti di frequenza delle API e nuovi tentativi

Limiti di frequenza e nuovi tentativi fanno parte del contratto tra un client e un'API. Un client deve distinguere tra successo, errori di validazione, errori di autenticazione, limiti di frequenza ed errori temporanei del server. La scelta tra JSON e XML non cambia la semantica HTTP, e i valori IPv4/IPv6 vanno conservati senza dare per scontata la lunghezza di un indirizzo IPv4.

Come gestire la risposta

Convalida Content-Type, codice di stato, campi documentati e quota. Gestisci HTTP 429 separatamente, rispetta Retry-After quando è presente e usa un backoff esponenziale limitato con jitter. Valuta l'idempotenza prima di ritentare. Registra nei log identificatori di richiesta, stato e latenza, ma mai i segreti dell'API.

Il dettaglio che conta

Quando l'API restituisce 429, leggi Retry-After se presente invece di attendere alla cieca un intervallo fisso. Limita il numero di tentativi, aggiungi jitter al backoff esponenziale ed evita di ripetere automaticamente operazioni che possono creare effetti collaterali duplicati. Per una richiesta reale e il contratto API attuale, consulta l'API di 2IP.