Come implementare la limitazione della frequenza in Azure Gestione API

L'uso della limitazione della frequenza consente di limitare il numero di chiamate API a un utente o un servizio in un determinato intervallo di tempo. La limitazione della velocità consente di garantire un utilizzo equo e impedire a qualsiasi singolo utente o servizio di monopolizzare le risorse dell'API. Azure Gestione API (APIM) offre un modo pratico per implementare la limitazione della frequenza per le API.

Perché Azure Gestione API?

Azure Gestione API è 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 che è 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 API specifico. 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 frequenza, decidere i limiti di frequenza. 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 1000 chiamate al minuto per utente.

Per definire i limiti di frequenza per l'API in Azure Gestione API, usare i rate-limit criteri orate-limit-by-key. L'ultimo imposta un limite per tutti gli utenti, mentre quest'ultimo consente limiti per chiave identificata (ad esempio una sottoscrizione o un ID utente).

Ecco un esempio di criterio che limita le chiamate a 1000 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, Azure Gestione API invia un codice di stato 429 Troppe richieste, insieme all'intestazione retry-after di 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 frequenza sulle intestazioni di risposta

Per impostazione predefinita, Azure Gestione API non espone le informazioni sul limite di frequenza sulle intestazioni di risposta. Non comunicando limiti di frequenza rende difficile per le app evitare il superamento del limite e la limitazione. Per esporre le informazioni sul limite di frequenza, estendere i rate-limit criteri con le remaining-calls-header-name proprietà 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 si chiama ora l'API, ogni risposta include le ratelimit-remaining intestazioni e ratelimit-limit , che comunicano quante più chiamate l'API può gestire prima di superare il limite.

Riepilogo

L'implementazione della limitazione della frequenza in Azure Gestione API consente di creare API affidabili e scalabili. Usando la limitazione della frequenza, è possibile assicurarsi che l'API soddisfi in modo affidabile ed efficiente gli utenti. Ricorda, la chiave consiste nel trovare il giusto equilibrio – troppo restrittivo e potresti impedire l'usabilità; troppo leniente e si rischia di travolgere l'API. Con un'attenta pianificazione e monitoraggio continuo, è possibile ottenere questo equilibrio e mantenere un ambiente API integro.

Passaggi successivi

Testare che l'applicazione gestisce correttamente la limitazione della frequenza