Calcolatore limite di rate API

Le API pubbliche e private pubblicano quasi sempre un limite di rate, ad esempio cento richieste al minuto o mille all'ora. Chi deve inviare più traffico di quanto una singola finestra consenta deve suddividere il lavoro in batch e attendere tra di essi affinché il fornitore non risponda HTTP 429 né revochi le credenziali. Questo calcolatore di budget del limite di rate API accetta il massimo di richieste per finestra, il totale di richieste che Lei intende inviare e, in opzione, la durata della finestra in secondi. I limiti di rate non positivi falliscono con invalid_input e non vengono addebitati.

Come finestre, batch e ritardo La tengono sotto il limite

Il calcolatore non chiama l'API remota; dimensiona soltanto il Suo calendario affinché il Suo client possa dormire tra i batch.

Contratto di ingresso, campi di risposta e regole di validazione

Invii in POST un corpo JSON con rate_limit, un intero positivo di richieste consentite per finestra; desired_requests, un intero non negativo di chiamate che intende effettuare; e opzionalmente window_seconds, una lunghezza finita positiva di quella finestra in secondi che vale sessanta per impostazione predefinita se omessa. Ogni campo può arrivare come numero JSON o come stringa numerica. Campi mancanti, valori non finiti, desired_requests frazionario, rate_limit frazionario e qualsiasi rate_limit non strettamente positivo falliscono con invalid_input e un messaggio che nomina il campo. In caso di successo il corpo ripete rate_limit, desired_requests e window_seconds, poi restituisce windows_needed, batch_size (massimo di richieste per batch pieno, uguale a rate_limit quando resta lavoro), last_batch_size (il batch parziale finale, oppure un batch pieno quando D divide esattamente), full_batches (quanti batch usano la dimensione massima prima del resto), delay_between_batches_seconds, min_elapsed_seconds, max_requests_per_second come rate_limit diviso per window_seconds, e una breve stringa di formula che riafferma la regola del ceiling. Esempio: rate_limit cento, desired_requests trecentocinquanta, window_seconds sessanta produce quattro finestre, batch di cento, ultimo batch cinquanta, ritardo sessanta secondi e minimo trascorso centottanta secondi. Zero desired_requests restituisce zero finestre e zero ritardo senza errore, utile per pianificatori in dry-run.

Dove un calcolatore di budget del limite API rende

Alimentare quel conteggio più il limite di rate del fornitore in questo calcolatore produce un calendario di attesa che può inserire in un loop di worker senza tempeste di 429 per tentativi ed errori. I product manager che stimano quanto durerà un export massivo possono convertire un conteggio di documenti in tempo di orologio prima di promettere al cliente una finestra lo stesso giorno. La validazione fallita non consuma saldo. Gli script di integrazione che riempiono webhook, reindicizzano documenti di ricerca o migrano tenant spesso conoscono il conteggio totale degli elementi prima di iniziare. Gli strumenti di osservabilità e di chaos possono affermare che un generatore di carico sintetico non supera mai max_requests_per_second derivato dal limite pubblicato. Tenga la logica di calendario nel Suo client; usi questo endpoint come unica fonte di verità dell'aritmetica così che mobile, edge worker e job CI pianifichino allo stesso modo.