Condividi tramite

Configurare l'API per gli eventi inviati dal server

  • Articolo

SI APPLICA A: Sviluppatore | Basic | Basic v2 | Standard | Standard v2 | Premium | Premium v2

Questo articolo fornisce linee guida per la configurazione di un'API in Gestione API che implementa gli eventi inviati dal server (SSE). La SSE è basata sullo standard EventSource HTML5 per lo streaming (push) dei dati automatico in un client tramite HTTP dopo che un client ha stabilito una connessione.

Suggerimento

Gestione API offre anche il supporto nativo per API WebSocket, che mantengono aperta una connessione singola, persistente e bidirezionale tra un client e un server.

Prerequisiti

  • Un'istanza di API Management esistente. Crearne una se non è già stato fatto.
  • API che implementa gli eventi inviati dal server. Importare e pubblicare l'API nell'istanza di Gestione API usando uno dei metodi di importazione supportati.

Linee guida per i SSE

Seguire queste linee guida quando si usa Gestione API per raggiungere un'API back-end che implementa gli eventi inviati dal server.

  • Scegliere il livello di servizio per le connessioni HTTP a esecuzione prolungata. La crittografia del servizio di archiviazione si basa su una connessione HTTP a esecuzione prolungata supportata in determinati piani tariffari Gestione API. Le connessioni a esecuzione prolungata sono supportate nei livelli classici e v2 Gestione API, ma non nel livello Consumo.

  • Mantenere attive le connessioni inattive: se una connessione tra client e back-end potrebbe rimanere inattiva per 4 minuti o più, implementare un meccanismo per mantenere attiva la connessione. Ad esempio, abilitare un segnale keepalive TCP nel back-end della connessione o inviare il traffico dal lato client almeno una volta per 4 minuti.

    Questa configurazione è necessaria per eseguire l'override del timeout di sessione inattivo di 4 minuti applicato da Azure Load Balancer, usato nell'infrastruttura di Gestione API.

  • Inoltrare immediatamente gli eventi ai client: disattivare il buffer delle risposte nei criteri forward-request in modo che gli eventi vengano immediatamente inoltrati ai client. Ad esempio:

    <forward-request timeout="120" fail-on-error-status-code="true" buffer-response="false"/>

  • Evitare altri criteri che memorizzano nel buffer le risposte: alcuni criteri, ad esempio validate-content, possono anche memorizzare nel buffer il contenuto della risposta e non devono essere usati con le API che implementano l’SSE.

  • Evitare di registrare il corpo della richiesta/risposta per Monitoraggio di Azure, Application Insights e Hub eventi: è possibile configurare la registrazione delle richieste API per Monitoraggio di Azure o Application Insights usando le impostazioni di diagnostica. Le impostazioni di diagnostica consentono di registrare il corpo della richiesta/risposta in varie fasi dell'esecuzione della richiesta. Per le API che implementano la crittografia del servizio di archiviazione, questo può causare buffering imprevisto che può provocare dei problemi. Le impostazioni di diagnostica per Monitoraggio di Azure e Application Insights configurate nell'ambito globale/Tutte le API si applicano a tutte le API nel servizio. È possibile eseguire l'override delle impostazioni per le singole API in base alle esigenze. Quando si accede a Hub eventi, è possibile configurare l'ambito e la quantità di informazioni di contesto per la registrazione di richieste/risposte usando i log-to-eventhubs. Per le API che implementano la crittografia del servizio di archiviazione, assicurarsi di aver disabilitato la registrazione del corpo della richiesta/risposta per Monitoraggio di Azure, Application Insights e Hub eventi.

  • Disabilitare la memorizzazione nella cache delle risposte: per assicurarsi che le notifiche al client siano tempestive, verificare che memorizzazione nella cache delle risposte non sia abilitata. Per altre informazioni, vedere criteri di memorizzazione nella cache di Gestione API.

  • Testare l'API in fase di carico: seguire le procedure generali per testare l'API sotto carico per rilevare i problemi di prestazioni o configurazione prima di passare all'ambiente di produzione.

Passaggi successivi