Limitation du débit de l’API REST entrante

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 3 minutes de lecture
  • Pour éviter un nombre excessif de demandes REST API entrantes, définissez des règles qui limitent le nombre de demandes REST API entrantes traitées par heure. Vous pouvez créer des règles pour limiter les demandes d’utilisateurs spécifiques, d’utilisateurs ayant des rôles spécifiques ou de tous les utilisateurs.

    Remarque :
    Lorsque les demandes atteignent une instance, chaque nœud maintient une limite de taux par utilisateur. Toutes les 30 secondes, le nombre est validé dans la base de données. Par conséquent, une règle de limite de taux peut ne pas prendre effet pendant 30 secondes maximum.

    Priorité de limitation de taux

    Si une demande d’API REST entrante correspond à plusieurs règles de limite de débit pour la même ressource, la priorité de limitation de débit est appliquée comme suit :
    • L’ensemble de règles pour un utilisateur unique remplace les règles pour tous les utilisateurs et les règles pour les utilisateurs disposant d’un rôle.
    • Ensemble de règles pour les utilisateurs avec des règles de remplacement de rôle pour tous les utilisateurs.
    Dans cet exemple, il existe quatre règles de limite de taux pour la même ressource d’API REST : GET /now/v2/table/incident :
    Règles de limites de taux
    Ces règles de limite de taux sont appliquées dans l’ordre suivant :
    1. Limiter les incidents par utilisateur s’applique à l’utilisateur ITIL, qui peut soumettre jusqu’à 10 demandes par heure.
    2. Limiter les incidents par admin d’importation Le rôle s’applique à chaque utilisateur disposant du rôle import_admin. Chaque utilisateur disposant du rôle import_admin peut soumettre jusqu’à trois demandes par heure.
    3. Le rôle Limiter les incidents par itil s’applique à chaque utilisateur disposant du rôle itil. Chaque utilisateur disposant du rôle itil peut soumettre jusqu’à cinq demandes par heure.
    4. La limite d’incidents s’applique à tous les utilisateurs. Chaque utilisateur peut soumettre jusqu’à deux demandes par heure.

    Lorsque l’utilisateur ITIL effectue la demande GET /now/v2/table/incident, la demande correspond aux critères de trois règles : Limiter les incidents, Limiter les incidents par rôle ITIL et Limiter les incidents par utilisateur. Seule la règle Limiter les incidents par utilisateur est appliquée, car elle est prioritaire sur les autres règles. Par conséquent, l’utilisateur ITIL peut soumettre un maximum de 10 demandes par heure.

    Si un utilisateur dispose d’au moins deux rôles correspondant aux critères de plusieurs règles de limitation de débit pour une ressource d’API REST, la règle autorisant le plus petit nombre de requêtes s’applique aux demandes de l’utilisateur pour la ressource. Pour les exemples de règles de la figure ci-dessus, supposons que l’utilisateur Abel Tuter possède à la fois le rôle import_admin et le rôle itil. Lorsqu’Abel Tuter envoie une demande, celle-ci répond aux critères de la règle Limiter les incidents par rôle administrateur et de la règle Limiter les incidents par rôle itil . Seule la règle Limiter les incidents par le rôle administrateur est appliquée, car c’est celle qui autorise le plus petit nombre de demandes. Par conséquent, Abel Tuter peut soumettre un maximum de trois demandes par heure.

    En-têtes de réponse de l’API REST

    Vous pouvez générer des demandes d’API REST entrantes à l’aide de ou Utiliser l’explorateur d’API REST d’un client HTTP, tel que Postman. Si la demande correspond à une règle de limite de débit, plusieurs en-têtes de réponse HTTP fournissent des informations sur la limitation de débit :
    • X-RateLimit-Limit affiche le nombre de demandes autorisées par heure.
    • X-RateLimit-Reset affiche le temps Unix jusqu’à la prochaine réinitialisation planifiée.
    • X-RateLimit-Rule affiche le sys_id de la règle de limite de taux en cours d’application.

      En-têtes de réponses de limite de taux

    Si une demande est refusée parce qu’elle dépasse la limite de taux, le système renvoie un en-tête de réponse Réessayer après en plus des en-têtes de réponse sur la limitation de taux. L’en-tête de réponse Réessayer après affiche le nombre de secondes après lesquelles vous pouvez réessayer la demande pour éviter de dépasser la limite des taux. La réponse d’erreur suivante est renvoyée :
    {
        "error": {
            "message": "Rate limit exceeded",
            "detail": "Rate limit of 10 requests per hour for Table API exceeded"
        },
        "status": "failure"
    }

    L’état d’une demande refusée est 429 Trop de demandes.

    État de la réponse REST 429 Trop de demandes