Afin de répondre rapidement à votre appel d'APIREST — même lorsque d'autres clients exécutent des requêtes chronophages —New Relic inclut une protection contre les surcharges dans l'API.
Si vous interrogez une quantité de données suffisamment importante pour consommer des ressources importantes, le code de réponse et les en-têtes de l'API indiqueront que vous avez dépassé la capacité disponible pour votre clé API. Il s’agit d’une condition rare que la plupart des clients ne verront jamais. Seuls les clients dont l’utilisation de l’API est très gourmande en ressources le verront.
les clients seront limités à 1000 appels API par minute.
Réponses API
En fonctionnement normal, l’API n’ajoute aucun statut de protection contre les surcharges aux réponses. Vous n’avez aucune mesure à prendre.
Au cours de l'intervalle de temps reporting period , New Relic suit l'impact de chaque demande d'API sur notre système.
Voici les cas typiques qui peuvent déclencher une protection contre les surcharges ou une limitation de débit :
- Une API clé que vous utilisez a dépassé le nombre maximal de requests par minute.
- Notre système est généralement surchargé et nous avons besoin que certains comptes réduisent leurs rapports.
Dans le cas où une limitation de débit se produit, les événements suivants se produiront :
- Tout appel ultérieur à l'API échouera avec le code d'état HTTP 429 (trop de requests).
- Les en-têtes et le corps des réponses HTTP peuvent ou non contenir plus d’informations sur l’erreur.
- L'appel d'API sera à nouveau autorisé à la fin de la période de référence.
En-têtes
Voici les en-têtes HTTP qui apparaîtront dans les réponses API si vous avez dépassé la limite individuelle de votre clé API :
En-tête de surcharge | Signification |
|---|---|
| Nombre maximum de requests par minute. |
| Nombre de requests restantes dans cette période. |
| Horaire UNIX (nombre de secondes depuis le 1er janvier 1970) auquel se termine la période de rapport actuelle. API requests recevront une réponse après ce délai. |
| Créez un lien hypertexte vers ce document afin d'avoir immédiatement des informations supplémentaires. |
Voici les en-têtes HTTP qui apparaîtront dans les réponses de l'API en cas de problème général du système :
En-tête de surcharge | Signification |
|---|---|
| Nombre de secondes avant que vous ne deviez réessayer. |
Exemple
Voici un exemple de requête API indiquant que l'appelant a consommé toutes les ressources disponibles et que tout appel d'API supplémentaire sera à nouveau autorisé à midi le 1er février 2016 :
$curl -X GET 'https://api.newrelic.com/v2/applications.json' \> -H "Api-Key:$API_KEY" -iHTTP/1.1 429 Too Many RequestsContent-Type: application/json...X-RateLimit-Docs: https://docs.newrelic.com/docs/apis/rest-api-v2/requirements/api-overload-protection-preventing-429-errorsX-RateLimit-Reset: 1454313600X-RateLimit-Remaining: 0X-RateLimit-Limit: 1000{}Prévenir les erreurs de limitation de débit
Le remède le plus simple pour une erreur 429 est d’attendre la fin de la période de rapport avant d’envoyer votre prochaine demande d’API. Cependant, avec une gestion minutieuse de votre requête, vous pouvez éviter en premier lieu les erreurs de protection contre les surcharges.
Si vous savez que vous allez envoyer de nombreuses requêtes gourmandes en ressources, vous pouvez effectuer l’une des mesures préventives suivantes :
- Envoyez votre requête moins souvent ; en particulier, envoyez votre requête moins d'une fois par minute (le taux de rafraîchissement des données agent ).
- Mettez en cache les données de New Relic plutôt que de les demander à l'API à chaque fois.
- Utilisez la technique basée sur le curseur si vous devez demander des noms métriques et les résultats de sortie sur plusieurs pages.