Condizioni con variabili di flusso

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info

Le istruzioni condizionali sono una struttura di controllo comune in tutti i linguaggi di programmazione. Ad esempio, linguaggio di programmazione, la configurazione proxy API supporta le istruzioni condizionali per i flussi Policy, Steps e RouteRules. Se definisci istruzioni condizionali, definisci un comportamento dinamico per la tua API. Questo comportamento dinamico ti consente, ad esempio, di convertire il file XML in JSON dispositivi mobili o routing a un URL di backend in base al tipo di contenuti o al verbo HTTP della richiesta per creare un nuovo messaggio email.

Questo argomento mostra come utilizzare le condizioni per applicare dinamicamente le funzionalità di gestione delle API in senza scrivere codice.

Configurare istruzioni condizionali

Il comportamento condizionale viene implementato nei proxy API utilizzando una combinazione di condizioni e variabili. Un'istruzione condizionale viene creata utilizzando un elemento Condition. La seguente è una condizione vuota:

<Condition></Condition>

Per creare un'istruzione condizionale, aggiungi un operatore condizionale e una variabile per creare la seguente struttura:

<Condition>{variable.name}{operator}{"value"}</Condition>

Gli operatori condizionali supportati includono = (uguale a), != (non uguale a) e > (maggiore di). Per una migliore leggibilità, puoi anche scrivere le condizionali come testo: equals, notequals, greaterthan.

Quando lavori con i percorsi URI, puoi utilizzare ~/ o MatchesPath. Puoi anche abbinare le espressioni regolari JavaRegex con l'operatore ~~.

Le condizioni vengono utilizzate per definire i flussi condizionali del proxy API verso le risorse API backend, in Creare flussi condizionali verso le risorse dell'API backend. Per un elenco completo dei condizionali, consulta la sezione Riferimento alle condizioni.

Variabili

Le condizioni svolgono il loro compito valutando i valori delle variabili. Una variabile è un proprietà di una transazione HTTP eseguita da un proxy API o una proprietà di un proxy API configurazione. Ogni volta che un proxy API riceve una richiesta da un'app, Apigee Edge compila un lungo elenco di variabili associate ad elementi quali l'ora di sistema, le informazioni di rete dell'app, le intestazioni HTTP sui messaggi, la configurazione del proxy API, le esecuzioni dei criteri e così via. Ciò crea un contesto dettagliato che puoi utilizzare per configurare dichiarazioni condizionali.

Le variabili utilizzano sempre una notazione puntata. Ad esempio, le intestazioni HTTP del messaggio di richiesta disponibili come variabili denominate request.header.{header_name}. Quindi, per valutare Per l'intestazione Content-Type puoi utilizzare la variabile request.header.Content-type. Ad esempio, request.header.Content-type = "application/json" indica che il tipo di contenuti della richiesta deve essere JSON.

Immagina di dover creare un'affermazione condizionale che farà sì che una norma solo quando il messaggio di richiesta è GET. Per creare una condizione che valuti il verbo HTTP di una richiesta, crea l'istruzione condizionale riportata di seguito. La variabile in questa condizione è request.verb. Il valore della variabile è GET. L'operatore è =.

<Condition>request.verb = "GET"</Condition>
Puoi anche utilizzare: 
<Condition>request.verb equals "GET"</Condition>

Edge utilizza questa istruzione per valutare le condizioni. L'esempio riportato sopra restituisce true se il verbo HTTP associato alla richiesta è GET. Se il verbo HTTP associato alla richiesta è POST, l'istruzione restituisce false.

Per attivare il comportamento dinamico, puoi associare le condizioni a flussi, passaggi e regole di routing.

Quando colleghi una condizione a un flusso, crei un "flusso condizionale". Flussi condizionali vengono eseguiti solo quando la condizione è true. Puoi allegare tutti i criteri che vuoi a un flusso condizionale. Un flusso condizionale consente di creare regole di elaborazione altamente specializzate per i messaggi di richiesta o risposta che soddisfano determinati criteri.

Ad esempio, per creare un flusso che venga eseguito solo quando il verbo della richiesta è GET:

<Flows>
  <Flow name="ExecuteForGETs">
  <Condition>request.verb="GET"</Condition>
  </Flow>
</Flows>

Per creare un flusso per i comandi GET e un altro per i comandi POST:

<Flows>
  <Flow name="ExecuteForGETs">
  <Condition>request.verb="GET"</Condition>
  </Flow>
  <Flow name="ExecuteForPOSTs">
  <Condition>request.verb="POST"</Condition>
  </Flow>
</Flows>

Come mostrato nell'esempio di seguito, puoi applicare la condizione al passaggio del criterio stesso. La seguente condizione fa sì che il criterio VerifyApiKey venga applicato in modo forzato solo se un messaggio di richiesta è PUBBLICA.

<PreFlow name="PreFlow">
    <Request>
        <Step>
            <Condition>request.verb equals "POST"</Condition>
            <Name>VerifyApiKey</Name>
        </Step>
    </Request>
</PreFlow>

Dopo aver definito questi flussi condizionali, puoi collegare i criteri a questi flussi, abilitando un'API proxy per applicare un insieme di criteri per le richieste GET e un altro set di criteri per POST richieste.

Per informazioni di riferimento complete, consulta le seguenti risorse:

Esempio 1

L'esempio seguente mostra un singolo flusso condizionale denominato Convert-for-devices, configurato nel flusso di risposta ProxyEndpoint. Aggiungi la condizione come elemento all'entità a cui si applica. In questo esempio, la condizione è un componente del flusso. Pertanto, il flusso verrà eseguito ogni volta che l'istruzione restituisce il valore true.

<Flows>
  <Flow name="Convert-for-devices">
  <Condition>(request.header.User-Agent = "Mozilla")</Condition>
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

Per ogni richiesta ricevuta da un'app, Edge archivia i valori di tutte le intestazioni HTTP presenti come come la codifica one-hot delle variabili categoriche. Se la richiesta contiene un'intestazione HTTP denominata User-Agent, questa intestazione e il suo valore vengono memorizzati come una variabile denominata request.header.User-Agent.

Data la configurazione di ProxyEndpoint precedente, Edge controlla il valore request.header.User-Agent per verificare se la condizione ha come risultato vero.

Se la condizione è true, ovvero il valore della variabile request.header.User-Agent è uguale a Mozilla, poi il flusso condizionale e viene applicato il criterio XMLtoJSON denominato ConvertToJSON. In caso contrario, il flusso non viene eseguito e la risposta XML viene restituita non modificata (in formato XML) all'app richiedente.

Esempio 2

Usiamo un esempio specifico in cui devi trasformare il messaggio di risposta da XML a JSON, ma solo per i dispositivi mobili. Innanzitutto, crea il criterio che convertirà Risposta in formato XML dall'API Weather in formato JSON:

<XMLToJSON name="ConvertToJSON">
  <Options>
  </Options>
  <OutputVariable>response</OutputVariable>
  <Source>response</Source>
</XMLToJSON>

La configurazione dei criteri riportata sopra indica al proxy API di accettare il messaggio di risposta ed eseguire una conversione da XML a JSON con le impostazioni predefinite, quindi scrivi il risultato nella nuova risposta per creare un nuovo messaggio email. Se vuoi convertire un messaggio di richiesta da XML a JSON, devi semplicemente impostare entrambi questi valori in request.)

Poiché vuoi convertire le risposte da XML a JSON, devi configurare un flusso di risposta per eseguire la conversione. Ad esempio, per convertire tutte le risposte da XML a JSON prima che vengano restituite all'app client, configura il seguente flusso di risposta ProxyEndpoint.

<Flows>
  <Flow name="Convert-for-devices">
    <Response>
      <Step><Name>ConvertToJSON</Name></Step>
    </Response>
  </Flow>
</Flows>

Quando richiami l'API utilizzando la richiesta standard, la risposta è formattata in JSON.

Tuttavia, il tuo obiettivo è convertire le previsioni meteo in JSON solo quando il cliente che ha inviato la richiesta è un dispositivo mobile. Per attivare questo comportamento dinamico, devi aggiungere un'istruzione condizionale al flusso.

Testa il condizionale flusso

In questa richiesta di esempio, l'intestazione HTTP User-Agent è impostata su Mozilla, che determina la valutazione dell'istruzione condizionale in true e della condizione condizionale il flusso Convert-for-devices.

$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

oppure, per la formattazione del codice, se Python è disponibile:

$ curl -H "User-Agent:Mozilla" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282 | python -mjson.tool

Esempio di risposta:

. . .

"yweather_forecast": [
         {
              "code": "11",
              "date": "12 Dec 2012",
              "day": "Wed",
              "high": "55",
              "low": "36",
              "text": "Showers"
          },
          {
              "code": "32",
              "date": "13 Dec 2012",
              "day": "Thu",
              "high": "56",
              "low": "38",
              "text": "Sunny"
          }
      ]
  }

. . .

Una richiesta inviata senza l'intestazione User-Agent o con un valore diverso da Mozilla genererà una risposta in formato XML.

$ curl http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

Viene restituita la risposta XML non modificata.

Esempio di risposta:

<yweather:forecast day="Wed" date="12 Dec 2012" low="36" high="55" text="Showers" code="11" /> <yweather:forecast day="Thu" date="13 Dec 2012" low="38" high="56" text="Sunny" code="32" />

Corrispondenza di pattern

Questa sezione descrive come utilizzare la corrispondenza dei pattern con le condizioni in un flusso Apigee.

Operatori

Questa sezione descrive come utilizzare i seguenti operatori di corrispondenza dei pattern negli statement condizionali:

Corrisponde a

Diamo un'occhiata alla sezione o "~" l'operatore condizionale. Questi due operatori sono Uguale: la versione inglese, "Matches", è considerata un'opzione più leggibile.

Riepilogo: le "Corrispondenze" offre due possibilità. Corrisponde alla stringa in modo letterale o esegui una corrispondenza con caratteri jolly con "*". Come previsto, il carattere jolly corrisponde a zero o più caratteri. Vediamo come funziona.

Il seguente XML mostra una condizione Step. Esegue il criterio SomePolicy quando la condizione restituisce true. In questo esempio, testiamo la variabile proxy.pathsuffix, una variabile integrata in Edge che memorizza il suffisso del percorso della richiesta. Tieni presente, tuttavia, che puoi verificare il valore di qualsiasi variabile di flusso contenente una stringa. Quindi, in questo caso, se il percorso di base la richiesta in arrivo è /animals e la richiesta è /animals/cat, poi il suffisso del percorso è la stringa letterale "/cat".

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix Matches "/cat")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Domanda: quale suffisso del percorso proxy causerà l'esecuzione di SomePolicy? C'è con una sola possibilità.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? Sì, perché il suffisso del percorso proxy corrisponde a "/cat" in modo esatto. Non verrà eseguito se il suffisso è /bat o /dog o "/" o qualsiasi altro.

Ora, considera questa istruzione condizionale in cui utilizziamo il carattere jolly "*":

<Condition>(proxy.pathsuffix Matches "/*at")</Condition>

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? Sì, perché il carattere jolly corrisponde a qualsiasi carattere e ""/cat" è una corrispondenza.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/bat

Il criterio viene eseguito? Sì, perché il carattere jolly corrisponde a qualsiasi carattere, "/bat" è una corrispondenza.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/owl

Il criterio viene eseguito? Ovviamente no, anche se il carattere jolly corrisponde a "o", le lettere "wl" non corrispondono.

Ora spostiamo il carattere jolly alla fine del suffisso:

<Condition>(proxy.pathsuffix Matches "/cat*")</Condition>

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? Sì, perché il carattere jolly corrisponde a zero o più caratteri qualsiasi.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/bat

Il criterio viene eseguito? No, "/bat" non corrisponde.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat123

Il criterio viene eseguito? Sì, il carattere jolly corrisponde a zero o più caratteri, pertanto "123" genera una corrispondenza.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat/bird/mouse

Il criterio viene eseguito? Sì, perché il carattere jolly corrisponde a zero o più caratteri, quindi "/bird/mouse" produce una corrispondenza. Tieni presente che un'espressione come questa può metterti nei guai perché corrisponde a tutto ciò che segue i caratteri letterali.

Domanda: l'operatore Corrispondenze è sensibile alle maiuscole?

Sì. Supponiamo che tu abbia una condizione come questa:

<Condition>(proxy.pathsuffix Matches "/*At")</Condition>

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? No, il carattere jolly corrisponde a qualsiasi lettera (indipendentemente dalle maiuscole), ma la lettera "a" minuscola non corrisponde a "A".

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/bAt

Il criterio viene eseguito? Sì, la richiesta corrisponde.

Domanda: come faccio a eseguire l'escapismo dei caratteri con l'operatore Corrispondenze?

Utilizza la percentuale "%" per l'interpretazione letterale dei caratteri riservati. Ad esempio:

<Condition>(proxy.pathsuffix Matches "/c%*at")</Condition>

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? No, l'operatore Corrispondenze sta cercando la stringa letterale "c*a".

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/c*at

Domanda:il criterio viene eseguito?

Sì, questo percorso, anche se un po' insolito, corrisponde.

JavaRegex

Come puoi vedere, l'operatore "Corrispondenze" è ideale per situazioni semplici. Ma puoi utilizzare un altro l'operatore "JavaRegex" o "~~" dell'operatore telefonico. Questi due sono lo stesso operatore, ad eccezione del fatto che JavaRegex è considerata più leggibile. Si chiama JavaRegex perché consente la corrispondenza di pattern di espressioni regolari e Edge segue le stesse regole delle classi nel package java.util.regex nel linguaggio Java. Il funzionamento dell'operatore JavaRegex è molto diverso Corrisponde all'operatore, quindi è importante non confonderli.

Riepilogo: l'operatore "JavaRegex" ti consente di utilizzare la sintassi delle espressioni regolari nelle affermazioni condizionali.

Il seguente codice mostra una condizione Step. Esegue il criterio SomePolicy se la condizione restituisce true. In questo esempio, testiamo la variabile proxy.pathsuffix, una variabile integrata in Edge che memorizza il suffisso del percorso della richiesta. Se il percorso di base della richiesta in entrata è /animals e la richiesta è /animals/cat, il suffisso del percorso è la stringa letterale "/cat".

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix JavaRegex "/cat")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Domanda: quale suffisso del percorso proxy causerà l'esecuzione di SomePolicy? Come accade con l'operatore Corrisponde, in questo caso esiste una sola possibilità.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? Sì, perché il suffisso del percorso del proxy corrisponde esattamente a "/cat". Non verrà eseguito se il suffisso è /bat o /dog o qualcos'altro.

Ora creiamo un'espressione regolare utilizzando il quantificatore "*". Questo quantificatore corrisponde a 0 del carattere precedente.

<Condition>(proxy.pathsuffix JavaRegex "/c*t")</Condition>

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? No! Il quantificatore "*" corrisponde a zero o più caratteri precedenti, ovvero un "c".

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/ccccct

Il criterio viene eseguito? Sì, perché il carattere jolly corrisponde a zero o più caratteri che lo precedono.

Dopodiché usiamo "?" quantificatore, che corrisponde una volta al carattere precedente o meno .

<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? Sì. "?" quantificatore corrisponde a zero o a un'occorrenza di il carattere precedente, "a".

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/ct

Il criterio viene eseguito? Sì. "?" quantificatore corrisponde a uno o nessuno del carattere precedente. In questo caso, non esiste una "a" , quindi viene restituito come true.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/caat

Il criterio viene eseguito? No. Il quantificatore "?" corrisponde a uno dei caratteri precedenti, ovvero un "a".

Dopodiché usiamo "[abc]" o "raggruppamento" lo stile dell'espressione regex. Corrisponde ai caratteri "a", "b" o "c".

<Condition>(proxy.pathsuffix JavaRegex "/[cbr]at")</Condition>

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? Sì. Qui utilizziamo le espressioni regolari e "[cbr]" corrisponde a "c", "b" OR "r". Queste chiamate sono anche corrispondenze:

GET http://artomatic-test.apigee.net/matchtest/bat

GET http://artomatic-test.apigee.net/matchtest/rat

Ma non è una corrispondenza:

GET http://artomatic-test.apigee.net/matchtest/mat

Domanda: l'operatore JavaRegex è sensibile alle maiuscole?

Sì. Supponi di avere una condizione come questa:

<Condition>(proxy.pathsuffix JavaRegex "/ca?t")</Condition>

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat

Il criterio viene eseguito? Sì, la regex corrisponde a zero o uno dei caratteri precedenti, ovvero "a".

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cAt

Domanda: il criterio viene eseguito?

No, perché la "A" maiuscola non corrisponde alla lettera "a" minuscola.

MatchesPath

L'operatore MatchesPath può essere specificato anche in questo modo "~/". Un po' come Matches (~) e gli operatori JavaRegex (~~). MatchesPath è completamente diverso.

Ricorda solo che questo operatore considera un percorso come una serie di parti. Pertanto, se il percorso è /animals/cats/wild, puoi immaginarlo come costituito dalle parti "/animals", "/cats" e "/wild".

L'operatore MatchesPath consente di utilizzare due notazioni di caratteri jolly: un asterisco singolo (*) e un asterisco doppio (**). L'asterisco singolo corrisponde a un elemento del percorso. Il doppio asterisco corrisponde a uno o più elementi del percorso.

Ecco un esempio. In questo esempio testiamo la variabile proxy.pathsuffix, una variabile integrata in Edge che archivia il suffisso del percorso della richiesta. Tieni presente, tuttavia, che testare il valore di qualsiasi variabile di flusso contenente una stringa.

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/*")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Domanda: quale suffisso del percorso del proxy causerà l'esecuzione di SomePolicy?

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/animals

Domanda: il criterio viene eseguito?

No, perché la condizione richiede un altro elemento di percorso dopo "/animals", come specificato da "/*".

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/animals/

Il criterio viene eseguito? Sì, il percorso ha un altro elemento percorso (la parte dopo "/animals/"), ma è semplicemente vuoto.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats

Il criterio viene eseguito? Sì, perché il percorso contiene chiaramente un elemento ("/cats") che segue "/animals"

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild

Domanda: il criterio viene eseguito?

No, perché il singolo asterisco corrisponde a un solo elemento del percorso e questa API ha più di un elemento dopo "/animals".

Ora utilizziamo il doppio asterisco:

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/**")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Domanda: quale suffisso del percorso proxy causerà l'esecuzione di SomePolicy?

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/animals

Il criterio viene eseguito? No, perché la condizione richiede almeno un elemento del percorso successivo specificato da "/**".

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/animals/

Il criterio viene eseguito?

Sì, il percorso ha un altro elemento (la parte successiva "/animals/"), ma è vuoto.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats

Il criterio viene eseguito?

Sì, perché il percorso ha almeno un elemento che segue "/animals"

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild

Il criterio viene eseguito?

Sì, perché il percorso contiene più di un elemento dopo "/animals"

Combinazione di asterischi

Puoi utilizzare combinazioni di asterischi singoli (*) e doppi (**) per perfezionare ulteriormente la corrispondenza dei percorsi.

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>(proxy.pathsuffix MatchesPath "/animals/*/wild/**")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Chiamata API:

Tutte queste chiamate API produrranno una corrispondenza:

GET http://artomatic-test.apigee.net/matchtest/animals/cats/wild/

e

GET http://artomatic-test.apigee.net/matchtest/animals/dogs/wild/austrailian

e

GET http://artomatic-test.apigee.net/matchtest/animals/birds/wild/american/finches

Risorse API

I servizi RESTful sono raccolte di risorse API. Una risorsa API è un percorso URI che identifica un'entità a cui gli sviluppatori possono accedere chiamando la tua API. Ad esempio: Se il tuo servizio fornisce previsioni meteo e previsioni meteo, il servizio di backend potrebbe definire due risorse API:

  • http://mygreatweatherforecast.com/reports
  • http://mygreatweatherforecast.com/forecasts

Quando crei un proxy API (come mostrato in Creare il primo proxy API), almeno stai creando un l'URL di base dell'alias che mappa al servizio di backend. Ad esempio:

URL di base del backend URL del proxy API nuovo/equivalente
http://mygreatweatherforecast.com http://{your_org}-{environment}.apigee.net/mygreatweatherforecast

A questo punto puoi effettuare chiamate API al tuo backend utilizzando uno dei due URL di base. Ma quando utilizzi l'URL del proxy API, le cose iniziano a farsi interessanti.

Oltre all'analisi delle API che Edge inizia a raccogliere quando utilizzi il proxy API, ti permettono anche di definire i flussi condizionali che mappano alle risorse sul tuo backend. In sostanza, "Se quando arriva una chiamata GET alla risorsa /reports, Edge dovrebbe fare qualcosa."

L'immagine seguente mostra la differenza di comportamento tra due URL che accedono allo stesso backend. uno è l'URL della risorsa senza proxy, l'altro è un proxy API Edge con un condizionale alla stessa risorsa di backend. Di seguito descriveremo i flussi condizionali in modo più dettagliato.

Come i proxy API vengono mappati a risorse di backend specifiche

Con un URL del proxy API mappato all'URL di base del servizio di backend (quando crei proxy), puoi aggiungere flussi condizionali a risorse specifiche, ad esempio /reports e /forecasts risorse menzionate in precedenza.

Supponiamo che tu voglia chiedere a Edge di "fare qualcosa" quando arrivano le chiamate /reports o /forecasts risorse. A questo punto non stai dicendo a Edge cosa fare, ma solo che deve ascoltare le chiamate a queste risorse. Per farlo, utilizza le condizioni. Nel proxy API Edge, puoi creare flussi condizionali per /reports e /forecasts. A scopo concettuale, il seguente XML del proxy API mostra come potrebbero essere queste condizioni.

<Flows>
    <Flow name="reports">
        <Description/>
        <Request/>
        <Response/>
        <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition>
    </Flow>
    <Flow name="forecasts">
        <Description/>
        <Request/>
        <Response/>
        <Condition>(proxy.pathsuffix MatchesPath "/forecasts") and (request.verb = "GET")</Condition>
    </Flow>
</Flows>

Queste condizioni sono la seguente: "Quando arriva una richiesta GET con /reports e /forecasts nell'URL, Edge farà quanto indicato dallo sviluppatore dell'API, tramite i criteri che colleghi a questi flussi.

Ecco un esempio di come indicare a Edge cosa fare quando una condizione è soddisfatta. Nel seguente XML proxy dell'API, quando viene inviata una richiesta GET a https://yourorg-test.apigee.net/mygreatweatherforecast/reports, Edge esegue il criterio "XML-to-JSON-1" nella risposta.

<Flows>
    <Flow name="reports">
        <Description/>
        <Request/>
        <Response>
            <Step>
                <Name>XML-to-JSON-1</Name>
            </Step>
        </Response>
        <Condition>(proxy.pathsuffix MatchesPath "/reports") and (request.verb = "GET")</Condition>
</Flow>

Oltre a questi flussi condizionali facoltativi, ogni proxy API è dotato anche di due flussi predefinite: un <PreFlow> eseguito prima dei flussi condizionali e un <PostFlow> eseguito dopo i flussi condizionali. Questi sono utili per eseguire i criteri quando viene effettuata qualsiasi chiamata a un proxy API. Ad esempio, se vuoi verificare la chiave API di un'app a ogni chiamata, indipendentemente dalla risorsa di backend a cui si accede, potrebbe inserire un criterio di verifica della chiave API su <PreFlow>. Per ulteriori informazioni sui flussi, consulta Configurazione dei flussi.

Creazione di flussi condizionali verso le risorse di backend

La definizione dei flussi condizionali verso le risorse di backend in un proxy API è completamente facoltativa. Tuttavia, questi flussi condizionali ti consentono di applicare una gestione e un monitoraggio granulari.

Sarai in grado di:

  • Applica la gestione in modo che rifletta la semantica del tuo modello API
  • Applica criteri e comportamento basato su script a singoli percorsi di risorse (URI)
  • Raccogli metriche dettagliate per i servizi di analisi

Ad esempio, immagina di dover applicare diversi tipi di logica al tuo backend da /developers alle risorse di /apps.

Per farlo, aggiungi due flussi condizionali nel proxy API: /developers e /apps.

Nella visualizzazione Sviluppa del riquadro di navigazione dell'editor del proxy API, fai clic sull'icona + accanto a predefinito in ProxyEndpoint.

Nella sezione "New Conditional Flow" (Nuovo flusso condizionale) , dovresti inserire le seguenti configurazioni chiave:

  • Nome flusso: Developers
  • Tipo di condizione: Percorso
  • Percorso: /developers

La condizione verrà attivata (e i criteri verranno eseguiti) se viene inviata una chiamata al proxy con /developers alla fine dell'URI.

Ora aggiungi un flusso condizionale per /apps e supponiamo che tu voglia che la condizione venga attivata sia sull'URI sia sul verbo POST in una richiesta. La configurazione prevede l'impostazione di quanto segue:

  • Nome del flusso: App
  • Tipo di condizione: percorso e verbo
  • Percorso: /apps
  • Verbo: POST

La condizione verrà attivata (e i criteri verranno eseguiti) se viene inviata una chiamata al proxy con /apps alla fine dell'URI e un verbo POST.

Nel riquadro Navigator, vedrai nuovi flussi per App e Sviluppatori.

Seleziona uno dei flussi per visualizzare la configurazione del flusso condizionale nell'editor proxy API visualizzazione codice:

<Flow name="Apps">
    <Description>Developer apps registered in Developer Services</Description>
    <Request/>
    <Response/>
    <Condition>(proxy.pathsuffix MatchesPath "/apps") and (request.verb = "POST")</Condition>
</Flow>

Come si può vedere, le risorse API sono semplicemente flussi condizionali che valutano il percorso URI del richiesta in entrata. La variabile proxy.pathsuffix identifica l'URI della richiesta che segue il BasePath configurato nella configurazione di ProxyEndpoint.

Ogni risorsa API che definisci viene implementata da un flusso condizionale nel proxy API. (Vedi Configurazione dei flussi.)

Dopo aver eseguito il deployment del proxy API nell'ambiente di test, esegui la richiesta seguente:

http://{org_name}-test.apigee.net/{proxy_path}/apps

farà sì che la condizione restituisca true e questo flusso, insieme alle eventuali i criteri di deployment.

La seguente condizione di esempio utilizza un'espressione regolare Java per riconoscere le chiamate effettuate al /apps risorsa con o senza barra finale (/apps o /apps/**):

<Condition>(proxy.pathsuffix JavaRegex "/apps(/?)") and (request.verb = "POST")</Condition>

Per ulteriori informazioni su questo tipo di condizione, consulta Come trovare corrispondenze indipendentemente ... nella community Apigee.

Modellazione di URI gerarchici

In alcuni casi, le risorse API saranno gerarchiche. Ad esempio, l'API Developer Services fornisce un metodo per elencare tutte le app appartenenti a uno sviluppatore. Il percorso dell'URI è:

/developers/{developer_email}/apps

Potresti avere risorse in cui viene generato un ID univoco per ogni entità di una raccolta, che a volte è annotata come segue:

/genus/:id/species

Questo percorso si applica allo stesso modo ai seguenti due URI:

/genus/18904/species
/genus/17908/species

Per rappresentare questa struttura in una risorsa API, puoi utilizzare i caratteri jolly. Ad esempio:

/developers/*/apps

/developers/*example.com/apps

/genus/*/species

risolverà in modo appropriato questi URI gerarchici come risorse API.

In alcuni casi, soprattutto per le API profondamente gerarchiche, potresti semplicemente voler risolvere tutto ciò che un certo frammento URI. A tal fine, utilizza un asterisco doppio jolly nella definizione della risorsa. Per Ad esempio, se definisci la seguente risorsa API: 
/developers/**

Questa risorsa dell'API risolverà i seguenti percorsi URI:

/developers/{developer_email}/apps
/developers/{developer_email}/keys
/developers/{developer_email}/apps/{app_id}/keys

Ecco come appare la condizione di flusso condizionale nella definizione del proxy API:

<Condition>(proxy.pathsuffix MatchesPath "/developers/**") and (request.verb = "POST")</Condition>

Altri esempi

Condizione collegata a RouteRule

<RouteRule name="default">
 <!--this routing executes if the header indicates that this is an XML call. If true, the call is routed to the endpoint XMLTargetEndpoint-->
  <Condition>request.header.content-type = "text/xml"</Condition>
  <TargetEndpoint>XmlTargetEndpoint</TargetEndpoint>
</RouteRule>

Condizione collegata a un criterio

<Step>
<!--the policy MaintenancePolicy only executes if the response status code is exactly 503-->
  <Condition>response.status.code = 503</Condition>
  <Name>MaintenancePolicy</Name>
</Step>

Flusso condizionale

<!-- this entire flow is executed only if the request verb is a GET-->
<Flow name="GetRequests">
  <Condition>request.verb="GET"</Condition>
  <Request>
    <Step>
<!-- this policy only executes if request path includes a term like statues-->
<Condition>request.path ~ "/statuses/**"</Condition>
      <Name>StatusesRequestPolicy</Name>
    </Step>
  </Request>
  <Response>
    <Step>
<!-- this condition has multiple expressions. The policy executes if the response code status is exactly 503 or 400-->
<Condition>(response.status.code = 503) or (response.status.code = 400)</Condition>
      <Name>MaintenancePolicy</Name>
    </Step>
  </Response>
</Flow>

Operatori di esempio nelle condizioni

Ecco alcuni esempi di operatori utilizzati per creare condizioni:

  • request.header.content-type = "text/xml"
  • request.header.content-length < 4096 && request.verb = "PUT"
  • response.status.code = 404 || response.status.code = 500
  • request.uri MatchesPath "/*/statuses/**"
  • request.queryparam.q0 NotEquals 10

Un esempio pratico: ignorare il carattere "/" alla fine di un percorso

Gli sviluppatori di Edge in genere vogliono gestire entrambi i suffissi del percorso: "/cat" e "/cat/". Questo perché alcuni utenti o client potrebbero chiamare la tua API con la barra aggiuntiva alla fine del percorso e devi essere in grado di gestirla nelle tue istruzioni condizionali. Questo caso d'uso esatto è stato discusso nella community di Apigee.

Se preferisci, puoi ottenere questo risultato senza utilizzare le espressioni regolari, come descritto di seguito:

    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Condition>((proxy.pathsuffix = "/cat") OR (proxy.pathsuffix = "/cat/")</Condition>
                <Name>SomePolicy</Name>
            </Step>
        </Request>
        <Response/>
    </PreFlow>

Questa è una buona opzione. Sia chiaro e leggibile.

Puoi fare la stessa cosa con le espressioni regolari in questo modo. Le parentesi vengono utilizzate per raggruppare non sono obbligatorie, ma non sono le regex dell'istruzione.

<Condition>(proxy.pathsuffix JavaRegex "/cat(/?)"</Condition>

Chiamate API:

GET http://artomatic-test.apigee.net/matchtest/cat
or
GET http://artomatic-test.apigee.net/matchtest/cat/

Il criterio viene eseguito? Sì. Tieni presente che in un'espressione regolare il carattere "?" significa: corrisponde a zero o a uno dei caratteri precedenti. Pertanto, "/cat" e "/cat/" sono corrispondenze.

Chiamata API:

GET http://artomatic-test.apigee.net/matchtest/cat/spotted

Il criterio viene eseguito? No. L'espressione regolare corrisponde a zero o a una sola occorrenza del carattere precedente e non è consentito altro.

Corrispondenza di stringhe arbitrarie con JavaRegex

In tutti gli esempi di questo argomento viene mostrato come associare una delle variabili di flusso predefinite: proxy.pathsuffix. È bene sapere che puoi eseguire la corrispondenza di pattern su qualsiasi stringa arbitraria o variabile di flusso, indipendentemente dal fatto che si tratti di una variabile di flusso integrata come proxy.pathsuffix.

Ad esempio, se hai una condizione che testa una stringa arbitraria, ad esempio una stringa restituita in un payload di backend o una stringa restituita da una ricerca del server di autenticazione, puoi utilizzare gli operatori di corrispondenza per testarla. Se utilizzi JavaRegex, l'espressione regolare verrà confrontata con l'intera stringa dell'oggetto. Se l'oggetto è "abc" e l'espressione regolare è "[a-z]", non esiste alcuna corrispondenza, perché "[a-z]" corrisponde esattamente a un carattere alfabetico. L'espressione "[a-z]+" funziona, così come "[a-z]*" e "[a-z]{3}".

Vediamo un esempio concreto. Supponiamo che il server di autenticazione restituisca un elenco di ruoli come una stringa separata da virgole: "editor, author, guest".

Per verificare la presenza del ruolo Editor, questa costruzione non funzionerà, perché "editor" è solo una parte dell'intera stringa.

<Condition>returned_roles ~~ "editor"</Condition>

Tuttavia, questa costruzione funzionerà:

<Condition>returned_roles ~~ ".*\beditor\b.*")</Condition>

Funziona perché tiene conto delle interruzioni di parola e di qualsiasi altra parte della stringa con .* .

In questo esempio, puoi anche testare l'attributo "editor" con l'operatore Corrispondenze:

<Condition>returned_roles ~~ "*editor*")</Condition>

Tuttavia, nei casi in cui è necessaria una maggiore precisione, JavaRegex è spesso una scelta migliore.

Escrezione delle virgolette doppie nelle espressioni JavaRegex

La sintassi delle condizioni richiede che un'espressione JavaRegex sia racchiusa tra virgolette doppie; Pertanto, se disponi Un'espressione regex che includa virgolette doppie è necessario un modo alternativo per trovarle. La risposta è Unicode. Ad esempio, supponiamo di passare in un'intestazione che include virgolette doppie, come la seguente: 
 -H 'content-type:multipart/related; type="application/xop+xml"'
Se provi a trovare una corrispondenza con l'intestazione in una condizione regex, riceverai un errore di condizione non valida perché l'espressione contiene le virgolette: 
request.header.Content-Type ~~ "(multipart\/related)(; *type="application\/xop\+xml\")"
La soluzione consiste nel sostituire le virgolette doppie basate su ASCII con l'equivalente Unicode \u0022. Ad esempio: la seguente espressione è valida e produce il risultato previsto: 
request.header.Content-Type ~~ "(multipart\/related)(; *type=\u0022application\/xop\+xml\u0022)"