Concatenamento di proxy API

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Puoi specificare che un proxy è l'endpoint di destinazione di un altro, collegando di fatto i due proxy in una catena di proxy. Il concatenamento dei proxy in questo modo può aiutarti a evitare un hop di rete e quindi a migliorare le prestazioni complessive.

Nota: ogni proxy nella catena viene fatturato come una chiamata e conteggiato come una chiamata ai fini dei limiti.

Nota: il concatenamento dei proxy fornisce un modo per riutilizzare i proxy. Per un altro modo in cui sviluppare componenti progettati espressamente per essere riutilizzati, consulta Flussi condivisi riutilizzabili.

Con il concatenamento dei proxy, specifichi che un proxy è l'endpoint di destinazione locale dell'altro. Anziché utilizzare l'elemento HTTPTargetConnection per effettuare una chiamata al secondo proxy, utilizzi l'elemento LocalTargetConnection.

<LocalTargetConnection>
    <APIProxy>myproxy2</APIProxy>
    <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>

Il concatenamento dei proxy può essere utile quando hai un proxy che offre alcune funzionalità discrete di basso livello che altri proxy utilizzeranno. Ad esempio, un proxy che espone operazioni di creazione/lettura/aggiornamento/eliminazione con un datastore di backend potrebbe essere il proxy di destinazione per più proxy che espongono i dati ai client.

Nota:i proxy a cui vuoi connetterti in questo modo devono trovarsi nella stessa organizzazione e nello stesso ambiente. Quando il proxy a cui ti connetti non rientra in questo ambito, valuta la possibilità di connetterti come risorsa esterna utilizzando l'elemento HTTPTargetConnection (come descritto in Riferimento alla configurazione del proxy API).

Nota:il seguente video mostra l'editor proxy classico nell'interfaccia utente di Apigee. Apigee sta introducendo una nuova versione dell'editor proxy, che ha un design diverso dalla versione classica mostrata nel video.

Video: guarda un breve video per scoprire di più sul concatenamento dei proxy API.

Come funziona il concatenamento dei proxy

Il concatenamento dei proxy utilizza una connessione locale per ridurre al minimo il sovraccarico di rete quando si chiama un proxy da un altro. Questa connessione locale è più efficiente perché bypassa le funzionalità di rete come bilanciatori del carico, router e processori di messaggi.

Di seguito è illustrata la differenza tra la connessione di proxy con HTTPTargetConnection e LocalTargetConnection (concatenamento di proxy):

Collega i proxy specificando che uno è un endpoint di destinazione locale dell'altro. Per la configurazione nel diagramma precedente (chiamata da proxy a proxy con concatenamento di proxy), devi specificare che ProxyB (/proxyB) è un endpoint di destinazione locale di ProxyA (/proxyA). In questo modo, le richieste in arrivo a ProxyA vengono inoltrate a ProxyB.

Puoi creare una connessione locale tra i proxy in due modi:

• Specificando il nome del proxy di destinazione e un nome ProxyEndpoint
• Specificando un percorso per l'endpoint del proxy di destinazione

Collega i proxy di destinazione all'interno di una configurazione TargetEndpoint utilizzando un elemento LocalTargetConnection, come descritto di seguito.

Avviso: quando concateni i proxy API, fai attenzione a evitare chiamate ricorsive a loop infinito nello stesso proxy API, il che potrebbe causare un sovraccarico del sistema.

Nota:se utilizzi Apigee hybrid v1.14 o versioni successive e la tua organizzazione ha il diritto di utilizzare la funzionalità Enhanced per-environment proxy limits, devi impostare la proprietà enhanceProxyLimits su true nel file overrides.yaml per utilizzare il concatenamento dei proxy.

Connessione dei proxy per nome proxy

Puoi specificare il proxy di destinazione in base al nome. Potresti scoprire che questa funzionalità è più utile quando crei la connessione da zero e sviluppi i proxy insieme. Se non conosci il nome (o il nome potrebbe cambiare), valuta la possibilità di connetterti al percorso dell'endpoint del proxy di destinazione, come descritto di seguito.

Quando ti connetti a un proxy di destinazione per nome, specifichi il nome del proxy e quello del relativo ProxyEndpoint.

L'esempio seguente specifica un proxy di destinazione denominato data-manager, insieme al nome ProxyEndpoint esposto da data-manager. Per informazioni di riferimento, consulta la sezione Riferimento per la configurazione dei proxy API.

Gli elementi <APIProxy> e <ProxyEndpoint> supportano la funzionalità di sostituzione dinamica delle stringhe chiamata modelli di messaggi.

Importante: se implementi il concatenamento dei proxy utilizzando il nome del proxy, il secondo proxy non mostrerà i risultati in Debug anche quando lo chiami. Utilizza invece Proxy chaining by path se devi utilizzare il debug sul secondo proxy.

<TargetEndpoint name="datamanager">
    <PreFlow name="PreFlow">
        <!-- PreFlow policies -->
    </PreFlow>
    <PostFlow name="PostFlow">
        <!-- PostFlow policies -->
    </PostFlow>
    <LocalTargetConnection>
        <APIProxy>data-manager</APIProxy>
        <ProxyEndpoint>default</ProxyEndpoint>
    </LocalTargetConnection>
</TargetEndpoint>

Connessione dei proxy per percorso

Puoi specificare il proxy di destinazione in base al percorso dell'endpoint. Potresti volerlo fare in questo modo quando non conosci il nome del proxy o quando il nome potrebbe cambiare.

Se il proxy è semplicemente il consumer del proxy di destinazione, ad esempio quando non sviluppi entrambi, il percorso potrebbe essere il modo più affidabile per connettersi. Ad esempio, se il proxy a cui ti connetti è sviluppato e gestito da un altro team, potresti voler connetterti utilizzando un percorso dell'endpoint affidabile.

L'esempio seguente specifica un proxy di destinazione all'indirizzo /v1/streetcarts/foodcarts/data-manager, dove l'host è considerato uguale al proxy corrente. Per informazioni di riferimento, consulta la sezione Riferimento per la configurazione dei proxy API.

<TargetEndpoint name="datamanager">
    <PreFlow name="PreFlow">
        <!-- PreFlow policies -->
    </PreFlow>
    <PostFlow name="PostFlow">
        <!-- PostFlow policies -->
    </PostFlow>
    <LocalTargetConnection>
        <Path>/v1/streetcarts/foodcarts/data-manager</Path>
    </LocalTargetConnection>
</TargetEndpoint>

L'elemento <Path> in <LocalTargetConnection> può essere una stringa oppure puoi utilizzare un modello di messaggio per assegnare un valore in modo dinamico.

Connessione dei proxy utilizzando la UI di Apigee

Puoi anche connettere i proxy, in base al nome o al percorso del proxy, utilizzando la UI di Apigee. Nell'esempio seguente, ci sono due proxy, ProxyA e ProxyB, e vuoi che ProxyB sia un endpoint di destinazione di ProxyA. Per collegare i proxy in base al nome del proxy, segui questi passaggi:

1. Vai all'elenco dei proxy.

Apigee nella console Cloud

Nella console Google Cloud , vai alla pagina Sviluppo proxy > Proxy API.

Vai ai proxy API

UI Apigee classica

1. Accedi alla UI Apigee.
2. Seleziona Sviluppa > Proxy nel riquadro a sinistra.
2. Nell'elenco dei proxy, seleziona ProxyA.
3. Fai clic sulla scheda Sviluppa.
4. Nel riquadro Codice, sostituisci la sezione <TargetEndpoint> dell'XML con quanto segue:

   <TargetEndpoint>
     <LocalTargetConnection>
       <APIProxy>ProxyB</APIProxy>
       <ProxyEndpoint>default</ProxyEndpoint>
     </LocalTargetConnection>
   </TargetEndpoint>

5. Fai clic su Salva.

Proxy concatenati, prodotti API e sicurezza

Il concatenamento dei proxy è ideale per i casi in cui entrambi i proxy si trovano nello stesso prodotto API. Per impostazione predefinita, entrambi sono disponibili per i clienti. Al momento Apigee non supporta il raggruppamento del secondo proxy in un prodotto API separato a cui i client non devono avere accesso.

Se il secondo proxy deve essere protetto dalle richieste dirette dei client, valuta la possibilità di aggiungere una logica per far esaminare al secondo proxy l'indirizzo IP del client. Nel caso di una chiamata effettuata con il concatenamento, l'indirizzo IP sarà locale. Il codice può convalidare la località prima di consentire l'elaborazione. Per un modo per farlo, consulta il criterio AccessControl.