Limitazione della frequenza
L’API limita la frequenza delle richieste usando un algoritmo leaky bucket. Ogni richiesta costa un certo numero di unità e queste unità escono dal bucket a una velocità costante. Questo mantiene il traffico a un ritmo regolare, consentendo comunque brevi picchi.
API GraphQL
La limitazione della frequenza per l’API GraphQL si basa sul costo di ogni richiesta, anziché su un numero fisso di richieste. Le sezioni seguenti illustrano le best practice per contenere tale costo e come leggere lo stato attuale del tuo limite di frequenza.
Best practice
- Usa le subscription invece di fare polling con le query per sapere quando i dati cambiano.
- Richiedi solo i campi che ti servono e usa
filterper restringere le query di elenco. - Le query di elenco restituiscono fino a 100 record per pagina, ma una pagina più grande costa più di una più piccola. Recuperare 100 record in una richiesta costa più che recuperarne 10, quindi richiedi meno record anziché più record. Consulta la paginazione per i dettagli.
- Se una richiesta viene rifiutata con un errore
429, il tuo bucket è pieno. Smetti di inviare richieste e invia nuove richieste solo dopo che è trascorso il tempo indicato dareset.
Limite di frequenza
Per proteggere l’API da query troppo complesse o che richiedono molte risorse, a ogni richiesta viene assegnato un costo in base alla quantità di dati richiesti. Ogni risposta a una richiesta valida, o a una richiesta che non supera la validazione di business, include un oggetto extensions.cost con il costo della richiesta e lo stato del tuo limite di frequenza. Viene omesso del tutto quando una richiesta non supera la validazione dello schema GraphQL.
cost· Integer- Il costo, in unità, della richiesta corrente.
limit· Integer- Il costo massimo, in unità, consentito nella finestra di limitazione corrente.
used· Integer- Quante unità sono già state consumate in questa finestra.
remaining· Integer- Quante unità hai ancora a disposizione prima di raggiungere il limite.
reset· Integer- Un timestamp UNIX, in secondi, che indica quando la quota viene ripristinata.
API REST
La limitazione della frequenza per l’API REST si applica al servizio di tile. A differenza dell’API GraphQL, lo stato del limite di frequenza viene restituito tramite gli header della risposta HTTP e ogni richiesta ha un costo fisso di 1 unità. Questi header vengono restituiti a ogni richiesta, comprese quelle non riuscite.
x-ratelimit-cost· Integer- Il costo, in unità, della richiesta corrente. Sempre
1per le richieste REST. x-ratelimit-limit· Integer- Il costo massimo, in unità, consentito nella finestra di limitazione corrente.
x-ratelimit-used· Integer- Quante unità sono già state consumate in questa finestra.
x-ratelimit-remaining· Integer- Quante unità hai ancora a disposizione prima di raggiungere il limite.
x-ratelimit-reset· Integer- Un timestamp UNIX, in secondi, che indica quando la quota viene ripristinata.
Limiti attuali
I limiti di frequenza vengono applicati per cliente, su una finestra di un minuto. Non è ancora previsto alcun limite predefinito. I limiti vengono configurati singolarmente per ogni cliente fino all’introduzione dei limiti predefiniti nel 2027.
Alcune query e mutation hanno anche limiti individuali inferiori al tuo limite complessivo. Questi sono impostati per prodotto, e talvolta per richiesta, anziché a livello globale.
Questo contenuto ti è stato utile?