Partager via

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

  • Article

S’APPLIQUE À : Développeur | Essentiel | Essentiel v2 | Standard | Standard v2 | Premium

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). Les SSE s’appuient sur la norme HTML5 EventSource pour transmettre (push) automatiquement des données à un client via HTTP après que celui-ci ait établi une connexion.

Conseil

Gestion des API offre également une prise en charge native des API WebSocket, qui maintiennent ouverte une connexion bidirectionnelle unique et persistante 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.

  • Choisir un niveau de service pour les connexions HTTP longues : SSE s’appuie sur une connexion HTTP longue prise en charge dans certains niveaux tarifaires de 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 TCP KeepAlive sur le serveur principal de la connexion, ou envoyez du trafic du côté client au moins une fois toutes les quatre minutes.

    Cette configuration est nécessaire pour remplacer le délai d’inactivité de la session de quatre minutes appliqué par l’équilibreur de charge Azure, qui est utilisé dans l’infrastructure de 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, cette action peut provoquer une mise en mémoire tampon inattendue 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, vérifiez que vous avez désactivé la journalisation du corps des requêtes/réponses pour Azure Monitor, Application Insights t 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.

Étapes suivantes