Come implementare la limitazione della frequenza in Azure Gestione API

Usando la limitazione della frequenza, è possibile limitare il numero di chiamate API che un utente o un servizio può effettuare in un periodo di tempo specifico. La limitazione della frequenza consente di garantire un utilizzo equo e impedire a qualsiasi singolo utente o servizio di monopolizzare le risorse API. Gestione API di Azure offre un modo pratico per implementare la limitazione della frequenza per le API.

Perché usare Gestione API di Azure?

Gestione API di Azure è un servizio cloud potente e versatile che consente alle organizzazioni di pubblicare API in sviluppatori esterni, partner e interni. Fornisce strumenti per proteggere, gestire e ridimensionare le chiamate API. Una delle sue funzionalità è il controllo della limitazione della frequenza, utile per mantenere l'integrità e l'affidabilità delle API.

Configurare la limitazione della frequenza in Azure Gestione API

Azure Gestione API usa criteri per applicare la limitazione della frequenza. È possibile definire questi criteri in ambiti diversi: globale, prodotto o specifico dell'API. Questa flessibilità consente di personalizzare la limitazione della frequenza in base ai requisiti e ai modelli di utilizzo dell'API.

Prima di iniziare a implementare la limitazione della velocità, decidere i limiti di velocità. I limiti impostati dipendono dalla capacità dell'API e dal traffico previsto. I limiti comuni vengono impostati come numero di chiamate al secondo, minuto o ora. Ad esempio, è possibile consentire 1.000 chiamate al minuto per utente.

Per definire i limiti di frequenza per la tua API in Gestione API di Azure, usa le policy rate-limit o rate-limit-by-key. Il rate-limit criterio imposta un limite per tutti gli utenti. I rate-limit-by-key criteri consentono limiti per ogni chiave identificata, ad esempio una sottoscrizione o un ID utente.

Ecco un esempio di criteri che limita le chiamate a 1.000 al minuto.

<policies>
  <inbound>
    <base />
    <rate-limit calls="1000" renewal-period="60" />
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

Quando si supera il numero specificato di chiamate, Gestione API di Azure invia un 429 Too Many Requests codice di stato, insieme all'intestazione retry-after della risposta e a un messaggio che indica quando è possibile riprovare.

HTTP/1.1 429 Too Many Requests
content-type: application/json
retry-after: 60
    
{
  "statusCode": 429,
  "message": "Rate limit is exceeded. Try again in 60 seconds."
}

Esporre le informazioni sul limite di velocità nelle intestazioni di risposta

Per impostazione predefinita, Azure Gestione API non espone informazioni sui limiti di frequenza per le intestazioni di risposta. La mancata comunicazione dei limiti di richiesta rende difficile per le app evitare di superare il limite e subire la limitazione. Per esporre le informazioni sui limiti di frequenza, estendere la politica rate-limit con le proprietà remaining-calls-header-name e total-calls-header-name.

<policies>
  <inbound>
    <base />
    <rate-limit calls="1000" renewal-period="60" remaining-calls-header-name="ratelimit-remaining" total-calls-header-name="ratelimit-limit" />
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

Quando ora chiami la tua API, ogni risposta include le intestazioni ratelimit-remaining e ratelimit-limit. Le intestazioni comunicano quante chiamate in più l'API può gestire prima che superi il limite.

Riepilogo

L'implementazione della limitazione della velocità in Azure Gestione API consente di creare API affidabili e scalabili. Usando la limitazione della frequenza, è possibile assicurarsi che l'API soddisfi gli utenti in modo affidabile ed efficiente. La chiave è trovare il giusto equilibrio. Se un limite di velocità è troppo rigoroso, è possibile ostacolare l'usabilità. Se un limite di velocità è troppo favorevole, si rischia di sovraccaricare l'API. Con un'attenta pianificazione e monitoraggio continuo, è possibile ottenere questo equilibrio e mantenere un ambiente API integro.

Testa i tuoi clienti

Dopo aver implementato la limitazione della frequenza nell'API, verificare che le app che chiamano l'API la gestiscano. Quando un client supera un limite impostato da rate-limit o rate-limit-by-key, API Management restituisce 429 Too Many Requests con un'intestazione Retry-After. I client che lo ignorano continuano a riprovare e restano soggetti al throttling.

Dev Proxy simula il comportamento di limitazione della frequenza configurato, con gli stessi limiti, intervalli di tempo e intestazioni di risposta, mentre l'app client continua a chiamare l'URL dell'API reale. Usare RateLimitingPlugin con rateLimit e resetTimeWindowSeconds impostati sui valori calls e renewal-period del criterio, costPerRequest impostato su 1 (il valore predefinito è 2, che dimezza il limite) e headerLimit e headerRemaining impostati sui nomi delle intestazioni del criterio. Aggiungi RetryAfterPlugin prima, in modo che Dev Proxy indichi quando un client chiama di nuovo troppo presto. Per informazioni dettagliate, vedere Simulare le risposte API del rate limit. Per installare Dev Proxy, vedere Configurare Dev Proxy.

• Come gestire la limitazione della frequenza: procedure consigliate per le app client

Passo successivo