Le API sono un ottimo modo per le applicazioni software di comunicare tra loro, perch\u00e9 permettono alle applicazioni software di interagire e condividere risorse o privilegi.<\/p>\n
Oggi molte aziende B2B offrono i loro servizi tramite API che possono essere usate da applicazioni realizzate con qualsiasi linguaggio e framework di programmazione. Tuttavia, questo le rende vulnerabili agli attacchi DoS e DDoS e pu\u00f2 anche portare a una distribuzione non uniforme della larghezza di banda tra gli utenti. Per affrontare questi problemi, viene implementata una tecnica nota come rate limiting delle API. L’idea \u00e8 semplice: si limita il numero di richieste che gli utenti possono fare all’API.<\/p>\n
In questa guida scopriremo cos’\u00e8 il rate limiting delle API, i vari modi in cui pu\u00f2 essere implementato e alcune best practice ed esempi da tenere a mente quando si impostano i limiti di richieste per le API.
\n
In parole povere, la limitazione delle richieste API si riferisce alla definizione di una soglia o di un limite al numero di accessi a un’API<\/a> da parte degli utenti. I limiti possono essere decisi in diversi modi.<\/p>\n Uno dei modi per impostare un limite di richieste \u00e8 quello di ridurre il numero di volte in cui un determinato utente pu\u00f2 accedere all’API<\/a> in un determinato periodo di tempo. Ci\u00f2 pu\u00f2 essere ottenuto contando il numero di richieste effettuate utilizzando la stessa chiave API o lo stesso indirizzo IP; quando viene raggiunta una soglia, le ulteriori richieste vengono limitate o negate.<\/p>\n In molti casi, gli sviluppatori vogliono distribuire equamente la larghezza di banda disponibile per le loro API in determinate localit\u00e0 geografiche.<\/p>\n Il recente servizio di anteprima di ChatGPT<\/a> \u00e8 un buon esempio di limitazione delle richieste in base alla posizione geografica<\/a>, in quanto ha iniziato a limitare le richieste in base alla posizione degli utenti sulla versione gratuita del servizio dopo l’introduzione della versione a pagamento. Questo ha senso in quanto la versione di anteprima gratuita doveva essere utilizzata da persone di tutto il mondo per generare un buon campione di dati di utilizzo per il servizio.<\/p>\n Il limite di richieste basato sul server \u00e8 un limite interno implementato sul lato server per garantire una distribuzione equa delle risorse del server come CPU, memoria, spazio su disco, ecc. Si realizza implementando un limite su ogni server di una distribuzione.<\/p>\n Quando un server raggiunge il suo limite, le richieste in arrivo vengono instradate verso un altro server con capacit\u00e0 disponibile. Se tutti i server hanno raggiunto la capacit\u00e0, l’utente riceve una risposta 429 Too Many Requests<\/a>. \u00c8 importante notare che i limiti di richieste basati sui server vengono applicati a tutti i client, indipendentemente dalla loro posizione geografica, dall’orario di accesso o da altri fattori.<\/p>\n\n Oltre alla natura dell’implementazione dei limiti di richieste, \u00e8 possibile classificare i limiti di richieste in base al loro effetto sull’utente finale. Alcuni tipi comuni sono:<\/p>\n Ci sono diversi motivi per cui \u00e8 necessario implementare il rate limiting nelle vostre API web<\/a>. Alcuni dei motivi principali sono:<\/p>\n Il primo motivo per cui dovreste prendere in considerazione l’implementazione di un limite di richieste delle API nella vostra applicazione \u00e8 quello di proteggere le vostre risorse dallo sfruttamento eccessivo da parte di utenti con intenti malevoli. Gli aggressori possono usare tecniche come gli attacchi DDoS<\/a> per monopolizzare l’accesso alle vostre risorse e impedire alla vostra app di funzionare normalmente per gli altri utenti. La presenza di un limite di richieste fa in modo che gli aggressori non abbiano vita facile se vogliono interrompere le vostre API.<\/p>\n Oltre a proteggere le vostre risorse, il limite di richieste vi permette di suddividere le risorse API tra gli utenti. Ci\u00f2 significa che potete creare modelli di prezzo differenziati e soddisfare le esigenze dinamiche dei vostri clienti senza che queste si ripercuotano sugli altri.<\/p>\n La limitazione delle tariffe equivale anche a una limitazione dei costi. Ci\u00f2 significa che potete distribuire in modo oculato le risorse tra i vostri utenti. Con una struttura partizionata, \u00e8 pi\u00f9 facile stimare i costi necessari per la manutenzione del sistema. Eventuali picchi possono essere gestiti in modo intelligente fornendo o disattivando la giusta quantit\u00e0 di risorse.<\/p>\n Molte API si basano su un’architettura distribuita che usa pi\u00f9 worker\/thread\/istanze per gestire le richieste in arrivo. In una struttura di questo tipo, potete usare dei limiti di richieste per controllare il carico di lavoro passato a ciascun nodo worker. Questo pu\u00f2 aiutarvi a garantire che i nodi worker ricevano carichi di lavoro equi e sostenibili. Potete facilmente aggiungere o rimuovere i worker quando necessario senza dover ristrutturare l’intero gateway API.<\/p>\n Un altro modo comune di controllare l’uso delle API \u00e8 quello di impostare un limite di burst (noto anche come throttling) invece di un limite di richieste. I limiti di burst sono limiti di richieste implementati per un intervallo di tempo molto piccolo, come alcuni secondi. Per esempio, invece di impostare un limite di 1,3 milioni di richieste al mese, potete impostare un limite di 5 richieste al secondo. Sebbene ci\u00f2 equivalga allo stesso traffico mensile, garantisce che i vostri clienti non sovraccarichino i vostri server inviando migliaia di richieste in una volta sola.<\/p>\n Nel caso dei limiti di burst, le richieste vengono spesso rimandate all’intervallo successivo invece di essere rifiutate. Inoltre, spesso si consiglia di usare sia i limiti di richieste che quelli di burst insieme per un controllo ottimale del traffico e dell’utilizzo.<\/p>\n Per quanto riguarda l’implementazione, ci sono alcuni metodi che potete usare per impostare il rate limiting delle API nella vostra applicazione. Tra questi ci sono:<\/p>\n Uno dei metodi pi\u00f9 semplici per limitare l’accesso alle API \u00e8 quello delle code di richieste. Le code di richieste si riferiscono a un meccanismo in cui le richieste in arrivo vengono memorizzate sotto forma di coda ed elaborate una dopo l’altra fino a un certo limite.<\/p>\n Un caso d’uso comune delle code di richieste \u00e8 la separazione delle richieste in arrivo da utenti gratuiti e a pagamento. Ecco come potete farlo in un’applicazione Express<\/a> usando il pacchetto Il throttling \u00e8 un’altra tecnica usata per controllare l’accesso alle API. Invece di interrompere l’accesso dopo il raggiungimento di una soglia, il throttling si concentra sull’attenuazione dei picchi di traffico delle API implementando piccole soglie per piccoli intervalli di tempo. Invece di stabilire un limite di richieste come 3 milioni di chiamate al mese, il throttling stabilisce limiti di 10 chiamate al secondo. Una volta che un cliente invia pi\u00f9 di 10 chiamate in un secondo, le richieste successive nello stesso secondo vengono automaticamente limitate, ma il cliente riacquista immediatamente l’accesso all’API nel secondo successivo.<\/p>\n Potete implementare il throttling in Express usando il pacchetto Potete testare l’applicazione usando uno strumento di test di carico come AutoCannon<\/a>. Potete installare AutoCannon eseguendo il seguente comando nel vostro terminale:<\/p>\n Potete testare l’applicazione con il seguente comando:<\/p>\n Il test usa 10 connessioni simultanee che inviano richieste all’API. Ecco il risultato del test:<\/p>\n Poich\u00e9 erano consentite solo 10 richieste al secondo (con un picco extra di 5 richieste), solo 114 richieste sono state elaborate con successo dall’API, mentre alle restanti richieste \u00e8 stato risposto con un codice di errore 503 che chiedeva di attendere un po’ di tempo.<\/p>\n Sebbene il rate limiting sembri un concetto semplice da implementare tramite una coda, in realt\u00e0 pu\u00f2 essere implementato in diversi modi che offrono altri vantaggi. Ecco alcuni algoritmi popolari che si usano per implementare il rate limiting:<\/p>\n L’algoritmo a finestra fissa \u00e8 uno dei pi\u00f9 semplici algoritmi di limitazione delle richieste. Limita il numero di richieste che possono essere gestite in un intervallo di tempo fisso.<\/p>\n Si stabilisce un numero fisso di richieste, per esempio 100, che possono essere gestite dal server API in un’ora. Ora, quando arriva la 101esima richiesta, l’algoritmo nega l’elaborazione. Quando l’intervallo di tempo si ripristina (cio\u00e8 nell’ora successiva), \u00e8 possibile elaborare altre 100 richieste in arrivo.<\/p>\n Questo algoritmo \u00e8 semplice da implementare e funziona bene in molti casi in cui \u00e8 necessario limitare la velocit\u00e0 sul lato server per controllare la larghezza di banda (a differenza della distribuzione della larghezza di banda tra gli utenti). Tuttavia, pu\u00f2 dare luogo a un traffico\/elaborazione a scatti verso i margini dell’intervallo di tempo fissato. L’algoritmo a finestra scorrevole \u00e8 un’alternativa migliore nei casi in cui \u00e8 necessaria un’elaborazione uniforme.<\/p>\n L’algoritmo a finestra scorrevole \u00e8 una variante dell’algoritmo a finestra fissa. Invece di usare intervalli di tempo fissi e predefiniti, questo algoritmo usa una finestra temporale mobile per monitorare il numero di richieste elaborate e in arrivo.<\/p>\n Invece di considerare gli intervalli di tempo assoluti (per esempio di 60 secondi ciascuno), come da 0 a 60, da 61 a 120 e cos\u00ec via, l’algoritmo a finestra mobile considera i 60 secondi precedenti a partire dal momento in cui viene ricevuta una richiesta. Supponiamo che una richiesta venga ricevuta all’82\u00b0 secondo; allora l’algoritmo conter\u00e0 il numero di richieste elaborate tra 22s e 82s (invece dell’intervallo assoluto 60s – 120s) per determinare se questa richiesta pu\u00f2 essere elaborata o meno. In questo modo si possono evitare situazioni in cui un gran numero di richieste viene elaborato sia al 59\u00b0 che al 61\u00b0 secondo, sovraccaricando il server per un periodo molto breve.<\/p>\n Questo algoritmo \u00e8 in grado di gestire meglio i picchi di traffico, ma pu\u00f2 essere pi\u00f9 difficile da implementare e mantenere rispetto all’algoritmo a finestra fissa.<\/p>\n In questo algoritmo, un contenitore (\u201cbucket\u201d) fittizio viene riempito di token e ogni volta che il server elabora una richiesta, un token viene prelevato dal contenitore. Quando il contenitore \u00e8 vuoto, il server non pu\u00f2 pi\u00f9 elaborare richieste. Ulteriori richieste vengono ritardate o negate fino a quando il contenitore non viene riempito di nuovo.<\/p>\n Il token bucket viene riempito a una velocit\u00e0 fissa (nota come \u201ctoken generation rate\u201d, velocit\u00e0 di generazione dei token) e il numero massimo di token che possono essere immagazzinati nel contenitore \u00e8 anch’esso fisso (noto come \u201cbucket depth\u201d, profondit\u00e0 del contenitore).<\/p>\n Controllando la velocit\u00e0 di rigenerazione dei token e la profondit\u00e0 del bucket, potete controllare la velocit\u00e0 massima del flusso di traffico consentito dall’API. Il pacchetto Il vantaggio principale di questo algoritmo \u00e8 che supporta i picchi di traffico, a patto che possa essere contenuto nella profondit\u00e0 del bucket. Questo \u00e8 particolarmente utile per il traffico imprevedibile.<\/p>\n L’algoritmo leaky bucket \u00e8 un altro algoritmo per gestire il traffico API. Invece di mantenere una profondit\u00e0 del bucket che determina quante richieste possono essere gestite in un lasso di tempo (come nel caso del token bucket), consente un flusso fisso di richieste dal bucket, come con un flusso costante di acqua da un contenitore che perde.<\/p>\n La profondit\u00e0 del contenitore, in questo caso, serve a determinare quante richieste possono essere messe in coda per essere elaborate prima che il contenitore inizi a traboccare, cio\u00e8 a negare le richieste in arrivo.<\/p>\n Il leaky bucket promette un flusso costante di richieste e, a differenza del token bucket, non gestisce i picchi di traffico.<\/p>\n Ora che avete capito cos’\u00e8 il rate limiting delle API e come viene implementato, condividiamo alcune buone pratiche da prendere in considerazione per implementarlo nella vostra applicazione.<\/p>\n Quando pensate di implementare un limite di richieste per le API, cercate sempre di offrire un livello gratuito adeguato che i vostri potenziali utenti possano usare per provare le vostre API. Non deve essere molto generoso, ma dovrebbe essere sufficiente per consentire agli utenti di testare comodamente la vostra API nella loro applicazione di sviluppo.<\/p>\n Se da un lato i limiti di richieste delle API sono fondamentali per mantenere la qualit\u00e0 degli endpoint delle API per i vostri utenti, dall’altro un piccolo livello gratuito non soggetto a limitazioni pu\u00f2 aiutarvi a conquistare nuovi utenti.<\/p>\n Quando un utente supera il limite di richieste dell’API che avete impostato, ci sono un paio di cose di cui dovreste occuparvi per garantire un’esperienza positiva agli utenti e allo stesso tempo proteggere le vostre risorse. Alcune domande che dovreste porvi e considerazioni da fare sono:<\/p>\n La prima cosa che dovete fare \u00e8 informare i vostri utenti che hanno superato il limite di richieste impostato per l’API . Per farlo, dovete modificare la risposta dell’API con un messaggio predefinito che spieghi il problema. \u00c8 importante che il codice di stato di questa risposta sia 429 “Too Many Requests”.<\/i> \u00c8 inoltre consuetudine spiegare il problema nel corpo della risposta. Il corpo di risposta di esempio mostrato sopra riporta il nome e la descrizione dell’errore e specifica anche una durata (solitamente in secondi) dopo la quale l’utente pu\u00f2 riprovare a inviare le richieste. Un corpo di risposta descrittivo come questo aiuta gli utenti a capire cos’\u00e8 andato storto e perch\u00e9 non hanno ricevuto la risposta che si aspettavano. Inoltre, consente loro di sapere quanto tempo attendere prima di inviare un’altra richiesta.<\/p>\n Un altro nodo di decisione \u00e8 cosa fare dopo che un utente ha superato il limite di impostato stabilito per l’API. Di solito si limita l’interazione dell’utente con il server inviando una risposta 429 “Too Many Requests”, come abbiamo visto sopra. Tuttavia, dovreste prendere in considerazione anche un approccio alternativo: il throttling.<\/p>\n Invece di interrompere completamente l’accesso alla risorsa del server, potete rallentare il numero totale di richieste che l’utente pu\u00f2 inviare in un determinato periodo di tempo. Questa soluzione \u00e8 utile quando volete dare agli utenti una piccola \u201cbacchettata\u201d, ma permettere loro di continuare a lavorare se riducono il volume delle richieste.<\/p>\n I limiti di richieste delle API sono spiacevoli: limitano l’interazione e l’utilizzo dei vostri servizi API da parte dei vostri utenti. Questo \u00e8 particolarmente grave per gli utenti che devono fare richieste simili pi\u00f9 volte, come per esempio accedere a un set di dati sulle previsioni del tempo che viene aggiornato solo settimanalmente o recuperare un elenco di opzioni per un menu a tendina che potrebbe essere cambiato una volta ogni morte di papa. In questi casi, un approccio intelligente sarebbe quello di implementare il caching.<\/p>\n Il caching<\/a> \u00e8 un’astrazione di archiviazione ad alta velocit\u00e0 che si implementa nei casi in cui il volume di accesso ai dati \u00e8 elevato, ma i dati non cambiano molto spesso. Invece di effettuare una chiamata API che potrebbe invocare pi\u00f9 servizi interni e comportare spese ingenti, potreste mettere in cache gli endpoint utilizzati pi\u00f9 di frequente in modo che la seconda richiesta venga servita dalla cache statica, che di solito \u00e8 pi\u00f9 veloce, pi\u00f9 economica e pu\u00f2 ridurre il carico di lavoro dei vostri servizi principali.<\/p>\n Pu\u00f2 esserci un altro caso in cui si riceve un numero insolitamente alto di richieste da parte di un utente. Anche dopo aver impostato un limite di richieste, l’utente raggiunge costantemente la sua capacit\u00e0 e viene limitato. Queste situazioni indicano la possibilit\u00e0 di un potenziale abuso dell’API.<\/p>\n Per proteggere i vostri servizi dal sovraccarico e mantenere un’esperienza uniforme per il resto degli utenti, dovreste considerare di limitare completamente l’accesso dell’utente sospetto all’API. Questo metodo \u00e8 noto come circuit breaking e, sebbene sembri simile al rate limiting, viene generalmente utilizzato quando il sistema si trova ad affrontare un sovraccarico di richieste e ha bisogno di tempo per rallentare e recuperare la qualit\u00e0 del servizio.<\/p>\n Sebbene i limiti di richieste delle API abbiano lo scopo di distribuire equamente le risorse tra i vostri utenti, a volte possono causare loro problemi inutili o addirittura indicare attivit\u00e0 sospette.<\/p>\n L’installazione di una solida soluzione di monitoraggio<\/a> per la vostra API pu\u00f2 aiutarvi a capire quanto spesso i limiti di richieste vengono raggiunti dai vostri utenti, a capire se \u00e8 necessario riconsiderare i limiti generali tenendo conto del carico di lavoro medio degli utenti e a identificare gli utenti che superano frequentemente i loro limiti (il che potrebbe indicare che hanno bisogno di un aumento dei loro limiti a breve o che devono essere monitorati per attivit\u00e0 sospette). In ogni caso, un monitoraggio attivo vi aiuter\u00e0 a capire meglio l’impatto dei limiti di richieste delle API.<\/p>\n Il rate limiting pu\u00f2 essere implementato su pi\u00f9 livelli (utente, applicazione o sistema). Molte persone commettono l’errore di impostare i limiti di richieste a uno solo di questi livelli e di aspettarsi che copra tutti i casi possibili. Sebbene non sia esattamente un anti-pattern, in alcuni casi pu\u00f2 rivelarsi inefficace.<\/p>\n Se le richieste in arrivo sovraccaricano l’interfaccia di rete del sistema, la limitazione delle richieste a livello di applicazione potrebbe non essere in grado di ottimizzare i carichi di lavoro. Per questo motivo \u00e8 meglio impostare le regole di limitazione del tasso a pi\u00f9 livelli, preferibilmente ai livelli pi\u00f9 alti della vostra architettura, per garantire che non si creino colli di bottiglia.<\/p>\n In questa sezione vediamo come testare i limiti di richieste dell’API per un determinato endpoint API e come implementare un controllo dell’utilizzo sul vostro client per assicurarvi di non esaurire i limiti dell’API remota.<\/p>\n Per identificare i limiti di richieste di un’API, il primo approccio dovrebbe essere quello di leggere i documenti dell’API per verificare se i limiti sono stati chiaramente definiti. Nella maggior parte dei casi, i documenti delle API vi indicheranno il limite e come \u00e8 stato implementato. Dovreste ricorrere al “test” del limite di richieste dell’API per identificarlo solo quando non riuscite a individuarlo dai documenti dell’API, dal supporto o dalla comunit\u00e0. Questo perch\u00e9 testare un’API per trovare il suo limite di richieste significa che finirete per esaurire il vostro limite di richieste almeno una volta, il che potrebbe comportare costi finanziari e\/o l’indisponibilit\u00e0 dell’API per un certo periodo.<\/p>\n Se volete identificare manualmente il limite di richieste, dovreste iniziare con un semplice strumento di test delle API come Postman per effettuare richieste manuali all’API e vedere se riuscite a esaurire il suo limite di richieste. Se non ci riuscite, potete utilizzare uno strumento di test di carico come Autocannon o Gatling per simulare un gran numero di richieste e vedere quante richieste vengono gestite dall’API prima che inizi a rispondere con un codice di stato 429.<\/p>\n Un altro approccio pu\u00f2 essere quello di usare uno strumento di controllo dei limiti di richieste come AppBrokers Tuttavia, se non siete sicuri del limite di richieste di un’API, potete sempre provare a stimare le vostre richieste e impostare dei limiti sul lato client per assicurarvi che il numero di richieste della vostra applicazione non superi tale numero. Scoprirete come farlo nella prossima sezione.<\/p>\n Se dal vostro codice effettuate delle chiamate a un’API, potreste voler implementare il throttle lato vostro per evitare di effettuare accidentalmente troppe chiamate all’API e di esaurire il vostro limite API. Ci sono diversi modi per farlo. Uno dei metodi pi\u00f9 diffusi \u00e8 quello di utilizzare il metodo throttle della libreria di utility lodash.<\/p>\n Prima di iniziare a fare il throttling di una chiamata API, dovrete creare un’API. Ecco un esempio di codice per un’API basata su Node.js che restituisce nella console il numero medio di richieste ricevute al minuto:<\/p>\n Una volta eseguita, l’applicazione restituir\u00e0 il numero medio di richieste ricevute ogni secondo:<\/p>\n Quindi, create un nuovo file JavaScript con il nome di test-throttle.js<\/b> e salvate in esso il seguente codice:<\/p>\n Una volta eseguito questo script, noterete che il numero medio di richieste del server salta quasi a 10:<\/p>\n E se questa API permettesse solo 6 richieste al secondo, per esempio? Vorreste mantenere il numero medio di richieste al di sotto di questa soglia. Tuttavia, se il vostro client invia una richiesta in base a un’attivit\u00e0 dell’utente, come il clic di un pulsante o uno scroll, potreste non essere in grado di limitare il numero di volte in cui la chiamata API viene attivata.<\/p>\n La funzione Quindi, aggiornate il file test-throttle.js<\/b> in modo che contenga il seguente codice:<\/p>\n Ora, se guardate i log del server, vedrete un output simile:<\/p>\n Questo significa che anche se la vostra applicazione chiama la funzione Quando lavorate con le API rate-limited, potreste incontrare una serie di risposte che indicano il superamento di un limite di richieste. Nella maggior parte dei casi, riceverete il codice di stato 429 con un messaggio simile a uno di questi:<\/p>\n Il messaggio che ricevete per\u00f2 dipende dall’implementazione dell’API che state usando. Questa implementazione pu\u00f2 variare e alcune API potrebbero anche non utilizzare affatto il codice di stato 429. Ecco alcuni altri tipi di codici di errore e messaggi relativi al limite di rate-limited:<\/p>\n Quando dovete impostare il limite di richieste per la vostra API, pu\u00f2 essere utile dare un’occhiata a come lo fanno alcuni dei migliori fornitori di API:<\/p>\n Quando si creano delle API, \u00e8 fondamentale garantire un controllo ottimale del traffico. Se non tenete sotto controllo la gestione del traffico, vi ritroverete presto con un’API sovraccarica e non funzionale. Al contrario, quando lavorate con un’API a velocit\u00e0 limitata, \u00e8 importante capire come funziona la limitazione delle richieste e come dovete usare l’API per garantire la massima disponibilit\u00e0 e utilizzo.<\/p>\n In questa guida avete imparato a conoscere la limitazione delle richieste delle API, i motivi per cui \u00e8 necessaria, come pu\u00f2 essere implementata e alcune best practice da tenere a mente quando si lavora con i limiti di richieste delle API.<\/p>\n Scoprite l’Hosting di Applicazioni<\/a> di Kinsta e avviate il vostro prossimo progetto Node.js<\/a> oggi stesso!<\/p>\n State lavorando con un’API in rate limiting? Oppure avete implementato la limitazione delle richieste nella vostra API? Fatecelo sapere nei commenti qui sotto!<\/i><\/p>\n","protected":false},"excerpt":{"rendered":" Le API sono un ottimo modo per le applicazioni software di comunicare tra loro, perch\u00e9 permettono alle applicazioni software di interagire e condividere risorse o privilegi. …<\/p>\n","protected":false},"author":199,"featured_media":70715,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[26232],"class_list":["post-70714","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-api"],"yoast_head":"\n1. Limiti basati sull’utente<\/h3>\n
2. Limiti basati sulla posizione<\/h3>\n
3. Limiti basati sul server<\/h3>\n
Tipi di limiti alle richieste API<\/h2>\n
\n
Perch\u00e9 il rate limiting \u00e8 necessario?<\/h2>\n
1. Proteggere l’accesso alle risorse<\/h3>\n
2. Dividere la quota tra gli utenti<\/h3>\n
3. Migliorare l’efficienza dei costi<\/h3>\n
4. Gestire il flusso tra i worker<\/h3>\n
Capire i limiti di burst<\/h2>\n
3 Metodi di implementazione del rate limiting<\/h2>\n
1. Code di richiesta<\/h3>\n
express-queue<\/code>:<\/p>\nconst express = require('express')\nconst expressQueue = require('express-queue');\n\nconst app = express()\n\nconst freeRequestsQueue = expressQueue({\n\tactiveLimit: 1, \/\/ Maximum requests to process at once\n\tqueuedLimit: -1 \/\/ Maximum requests allowed in queue (-1 means unlimited)\n});\n\nconst paidRequestsQueue = expressQueue({\n\tactiveLimit: 5, \/\/ Maximum requests to process at once\n\tqueuedLimit: -1 \/\/ Maximum requests allowed in queue (-1 means unlimited)\n});\n\n\/\/ Middleware that selects the appropriate queue handler based on the presence of an API token in the request\nfunction queueHandlerMiddleware(req, res, next) {\n\t\/\/ Check if the request contains an API token\n\tconst apiToken = req.headers['api-token'];\n\n\tif (apiToken && isValidToken(apiToken)) {\n \tconsole.log(\"Paid request received\")\n \tpaidRequestsQueue(req, res, next);\n\t} else {\n \tconsole.log(\"Free request received\")\n \tfreeRequestsQueue(req, res, next);\n \t}\n}\n\n\/\/ Add the custom middleware function to the route\napp.get('\/route', queueHandlerMiddleware, (req, res) => {\n\tres.status(200).json({ message: \"Processed!\" })\n});\n\n\/\/ Check here is the API token is valid or not\nconst isValidToken = () => {\n\treturn true;\n}\n\napp.listen(3000);<\/code><\/pre>\n2. Throttling<\/h3>\n
express-throttle<\/code>. Ecco un esempio di applicazione Express che mostra come impostare il throttling nella vostra applicazione:<\/p>\nconst express = require('express')\nconst throttle = require('express-throttle')\n\nconst app = express()\n\nconst throttleOptions = {\n\t\"rate\": \"10\/s\",\n\t\"burst\": 5,\n\t\"on_allowed\": function (req, res, next, bucket) {\n \tres.set(\"X-Rate-Limit-Limit\", 10);\n \tres.set(\"X-Rate-Limit-Remaining\", bucket.tokens);\n \tnext()\n\t},\n\t\"on_throttled\": function (req, res, next, bucket) {\n \t\/\/ Notify client\n \tres.set(\"X-Rate-Limit-Limit\", 10);\n \tres.set(\"X-Rate-Limit-Remaining\", 0);\n \tres.status(503).send(\"System overloaded, try again after a few seconds.\");\n\t}\n}\n\n\/\/ Add the custom middleware function to the route\napp.get('\/route', throttle(throttleOptions), (req, res) => {\n\tres.status(200).json({ message: \"Processed!\" })\n});\n\napp.listen(3000);<\/code><\/pre>\nnpm install autocannon -g<\/code><\/pre>\nautocannon http:\/\/localhost:3000\/route<\/code><\/pre>\nRunning 10s test @ http:\/\/localhost:3000\/route\n\n10 connections<\/span>\n\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Stat\t\u2502 2.5% \u2502 50% \u2502 97.5% \u2502 99% \u2502 Avg \t\u2502 Stdev \u2502 Max \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Latency \u2502 0 ms \u2502 0 ms \u2502 1 ms \u2502 1 ms \u2502 0.04 ms \u2502 0.24 ms \u2502 17 ms \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Stat \t\u2502 1% \t\u2502 2.5%\t\u2502 50%\t\u2502 97.5% \u2502 Avg\t\u2502 Stdev \u2502 Min \t\u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Req\/Sec \u2502 16591 \u2502 16591 \u2502 19695 \u2502 19903 \u2502 19144 \u2502 1044.15 \u2502 16587 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 Bytes\/Sec \u2502 5.73 MB \u2502 5.73 MB \u2502 6.8 MB \u2502 6.86 MB \u2502 6.6 MB \u2502 360 kB \u2502 5.72 MB \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\nReq\/Bytes counts sampled once per second.\n# of samples: 11\n114 2xx responses, 210455 non 2xx responses\n211k requests in 11.01s, 72.6 MB read<\/code><\/pre>\n3. Algoritmi di rate limiting<\/h3>\n
Algoritmo a finestra fissa<\/h4>\n
Algoritmo a Finestra Scorrevole<\/h4>\n
Algoritmo token bucket<\/h4>\n
express-throttle<\/code>, visto in precedenza, usa l’algoritmo del token bucket per limitare o controllare il flusso di traffico dell’API.<\/p>\nAlgoritmo leaky bucket<\/h4>\n
Le best practice per il rate limiting delle API<\/h2>\n
Offrire un livello gratuito agli utenti per esplorare i servizi<\/h3>\n
Decidere cosa succede quando il limite di richieste viene superato<\/h3>\n
Quale codice di errore e quale messaggio vedranno gli utenti?<\/h4>\n
\nEcco come potrebbe apparire un esempio di risposta:<\/p>\n{\n\t\"error\": \"Too Many Requests\",\n\t\"message\": \"You have exceeded the set API rate limit of X requests per minute. Please try again in a few minutes.\",\n\t\"retry_after\": 60\n}<\/code><\/pre>\nLe nuove richieste saranno limitate o completamente bloccate?<\/h4>\n
Considerare il caching e il circuit breaking<\/h3>\n
Controllare attentamente la configurazione<\/h3>\n
Implementare il rate limiting su pi\u00f9 livelli<\/h3>\n
Lavorare con i limiti di richieste delle API<\/h2>\n
Come verificare i limiti di richieste delle API<\/h3>\n
rate-limit-test-tool<\/a><\/code>. Strumenti dedicati come questo automatizzano il processo e vi forniscono anche un’interfaccia utente per analizzare attentamente i risultati del test.<\/p>\nCome limitare le chiamate API<\/h3>\n
const express = require('express');\nconst app = express();\n\n\/\/ maintain a count of total requests\nlet requestTotalCount = 0;\nlet startTime = Date.now();\n\n\/\/ increase the count whenever any request is received\napp.use((req, res, next) => {\n\trequestTotalCount++;\n\tnext();\n});\n\n\/\/ After each second, print the average number of requests received per second since the server was started\nsetInterval(() => {\n\tconst elapsedTime = (Date.now() - startTime) \/ 1000;\n\tconst averageRequestsPerSecond = requestTotalCount \/ elapsedTime;\n\tconsole.log(`Average requests per second: ${averageRequestsPerSecond.toFixed(2)}`);\n}, 1000);\n\napp.get('\/', (req, res) => {\n\tres.send('Hello World!');\n});\n\napp.listen(3000, () => {\n\tconsole.log('Server listening on port 3000!');\n});<\/code><\/pre>\nAverage requests per second: 0\nAverage requests per second: 0\nAverage requests per second: 0<\/code><\/pre>\n\/\/ function that calls the API and prints the response\nconst request = () => {\n\tfetch('http:\/\/localhost:3000')\n\t.then(r => r.text())\n\t.then(r => console.log(r))\n}\n\n\/\/ Loop to call the request function once every 100 ms, i.e., 10 times per second\nsetInterval(request, 100)<\/code><\/pre>\nAverage requests per second: 9.87\nAverage requests per second: 9.87\nAverage requests per second: 9.88<\/code><\/pre>\nthrottle()<\/code> della libreria lodash<\/code> pu\u00f2 aiutarvi in questo caso. Prima di tutto, installate la libreria eseguendo il seguente comando:<\/p>\nnpm install lodash<\/code><\/pre>\n\/\/ import the lodash library\nconst { throttle } = require('lodash');\n\n\/\/ function that calls the API and prints the response\nconst request = () => {\n\tfetch('http:\/\/localhost:3000')\n\t.then(r => r.text())\n\t.then(r => console.log(r))\n}\n\n\/\/ create a throttled function that can only be called once every 200 ms, i.e., only 5 times every second\nconst throttledRequest = throttle(request, 200)\n\n\/\/ loop this throttled function to be called once every 100 ms, i.e., 10 times every second\nsetInterval(throttledRequest, 100)<\/code><\/pre>\nAverage requests per second: 4.74\nAverage requests per second: 4.80\nAverage requests per second: 4.83\n<\/code><\/pre>\nrequest<\/code> 10 volte al secondo, la funzione di throttling fa in modo che venga chiamata solo 5 volte al secondo, aiutandovi a rimanere sotto il limite di richieste. Ecco come potete impostare il throttling lato client per evitare di esaurire i limiti di richieste delle API.<\/p>\nErrori comuni dei limiti di richieste delle API<\/h2>\n
\n
\n
Come i migliori fornitori di API implementano i limiti di richieste delle API<\/h2>\n
\n
retry_after<\/code> che potrete usare per attendere prima di inviare un’altra richiesta.<\/li>\nx-rate-limit-reset<\/code> che vi indicher\u00e0 quando potrete riprendere l’accesso.<\/li>\nX-Ratelimit-Used<\/code>, X-Ratelimit-Remaining<\/code> e X-Ratelimit-Reset<\/code> con cui potete determinare quando il limite potrebbe essere superato e in che modo<\/li>\nX-App-Usage<\/code> o X-Ad-Account-Usage<\/code> che vi aiuta a capire quando il vostro utilizzo sar\u00e0 limitato.<\/li>\n<\/ul>\n\nRiepilogo<\/h2>\n