Partager via


Configurer une API pour les événements envoyés par le serveur

S’applique à : Développeur | Essentiel | Essentiel v2 | Standard | Standard v2 | Premium | Premium v2

Cet article fournit des instructions pour la configuration d’une API dans Gestion des API qui implémente des événements envoyés par le serveur (SSE). SSE est basé sur la norme HTML5 EventSource pour la diffusion (push) de données automatiquement vers un client via HTTP une fois qu’une connexion cliente est établie.

Conseil

Gestion des API fournit également une prise en charge native des API WebSocket, qui conservent une connexion unique, persistante et bidirectionnelle ouverte entre un client et un serveur.

Prérequis

  • Disposer d’une instance d’API Management. Si vous ne l’avez pas déjà fait, créez-en un.
  • Une API qui implémente les SSE. Importez et publiez l’API sur votre instance Gestion des API à l’aide de l’une des méthodes d’importation prises en charge.

Instructions pour les SSE

Suivez ces instructions lors de l’utilisation de Gestion des API pour atteindre une API back-end qui implémente des SSE.

  • Choisissez un niveau de service pour les connexions HTTP longues : SSE s’appuie sur une connexion HTTP longue durée prise en charge dans certains niveaux tarifaires gestion des API. Les connexions longues sont prises en charge dans les niveaux de Gestion des API classique et v2, mais pas dans le niveau Consommation.

  • Maintenir en vie les connexions inactives : Si une connexion entre le client et le serveur principal peut rester inactive pendant quatre minutes ou plus, implémentez un mécanisme pour maintenir la connexion en vie. Par exemple, activez un signal keepalive TCP (Transmission Control Protocol) au niveau du back-end de la connexion ou envoyez le trafic du côté client au moins une fois par 4 minutes.

    Cette configuration est nécessaire pour remplacer le délai d’expiration de session inactif de 4 minutes que l’équilibreur de charge Azure applique, qui est utilisé dans l’infrastructure gestion des API.

  • Relayer immédiatement les événements aux clients : Désactivez la mise en mémoire tampon des réponses sur la stratégie forward-request afin que les événements soient immédiatement relayés aux clients. Par exemple :

    <forward-request timeout="120" fail-on-error-status-code="true" buffer-response="false"/>
    
  • Éviter les autres stratégies qui mettent en mémoire tampon les réponses : Certaines stratégies, telles que validate-content, peuvent également mettre en mémoire tampon le contenu des réponses et ne doivent pas être utilisées avec les API qui implémentent les SSE.

  • Évitez la journalisation du corps de requête/réponse pour Azure Monitor, Application Insights et Event Hubs – vous pouvez configurer la journalisation des requêtes d’API pour Azure Monitor ou Application Insights à l’aide des paramètres de diagnostic. Les paramètres de diagnostic vous permettent de journaliser le corps de la requête/réponse à différentes étapes de l’exécution de la requête. Pour les API qui implémentent SSE, la journalisation du corps de la demande/réponse peut entraîner une mise en mémoire tampon inattendue, ce qui peut entraîner des problèmes. Les paramètres de diagnostic pour Azure Monitor et Application Insights configurés dans l’étendue des API globales/Toutes s’appliquent à toutes les API du service. Vous pouvez remplacer les paramètres des API individuelles si nécessaire. Lorsque vous vous connectez à Event Hubs, vous configurez l’étendue et la quantité d’informations de contexte pour la journalisation des demandes/réponses à l’aide des log-to-eventhubs. Pour les API qui implémentent SSE, veillez à désactiver la journalisation des corps de requête/réponse pour Azure Monitor, Application Insights et Event Hubs.

  • Désactiver la mise en cache des réponses : Pour garantir la rapidité des notifications au client, vérifiez que la mise en cache des réponses n’est pas activée. Pour plus d’informations, consultez Stratégies de mise en cache de Gestion des API.

  • Tester l’API sous charge : Suivez les pratiques générales pour tester votre API sous charge afin de détecter les problèmes de performances ou de configuration avant de passer en production.