Che cos'è un criterio?

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X.
info

Apigee Edge ti consente di "programmare" il comportamento delle API senza scrivere codice, utilizzando i "criteri". Un criterio è come un modulo che implementa una funzione di gestione specifica e limitata. I criteri sono progettati per consentirti di aggiungere facilmente e in modo affidabile tipi comuni di funzionalità di gestione a un'API. I criteri forniscono funzionalità come sicurezza, limitazione di frequenza, trasformazione e mediazione capacità, evitando di dover codificare e gestire autonomamente queste funzionalità.

Non sei limitato all'insieme di tipi di criteri forniti da Apigee Edge. Puoi anche scrivere codice e script personalizzati (ad esempio applicazioni JavaScript e Node.js) che estendono la funzionalità del proxy API e ti consentono di innovare sulle funzionalità di gestione di base supportate dai criteri Apigee.

Guarda questo video per un'introduzione all'associazione e all'applicazione dei criteri.

Tipi di criteri

Tecnicamente, un criterio è un file di configurazione in formato XML. La struttura di ogni tipo di criterio (ad esempio, gli elementi di configurazione obbligatori e facoltativi) è definita da uno schema XML. Se hai familiarità con gli strumenti XML, ti consigliamo di prendere confidenza con gli schemi dei criteri negli esempi di API Platform su GitHub.

I tipi di criteri Edge sono raggruppati nelle seguenti categorie funzionali:

Gestione del traffico

I criteri nella categoria di gestione del traffico consentono di controllare il flusso di messaggi di richiesta e risposta tramite un proxy API. Questi criteri supportano il controllo a livello operativo e aziendale. Ti consentono di controllare la velocità effettiva non elaborata e possono anche controllare il traffico per ogni app. I tipi di criteri di gestione del traffico consentono di applicare le quote e aiutano anche a mitigare gli attacchi Denial of Service.

Sicurezza

I criteri nella categoria di sicurezza supportano l'autenticazione, l'autorizzazione e la sicurezza basata sui contenuti.

Mediazione

I criteri nella categoria di mediazione consentono di manipolare attivamente i messaggi mentre attraversano i proxy API. Consentono di trasformare i formati dei messaggi, da XML a JSON (e viceversa) o di trasformare un formato XML in un altro formato XML. Consentono inoltre di analizzare i messaggi, generare nuovi messaggi e modificare i valori nei messaggi in uscita. I criteri di mediazione interagiscono anche con i servizi di base esposti da API Services, consentendoti di recuperare dati su app, sviluppatori, token di sicurezza e prodotti API in fase di runtime.

Estensione

I criteri nella categoria di estensione consentono di sfruttare l'estensibilità di API Services per implementare un comportamento personalizzato nel linguaggio di programmazione di tua scelta.

Ogni tipo di criterio è documentato in dettaglio nella panoramica dei riferimenti ai criteri. Questo argomento illustra l'interazione generale, mostrando come creare i criteri e come associarli ai flussi in una configurazione del proxy API.

Deployment delle modifiche ai criteri

Affinché le modifiche ai criteri abbiano effetto, devi eseguire il deployment della revisione del proxy API in un ambiente. Dopo aver associato un criterio o apportato modifiche a un criterio esistente, utilizza l'UI di gestione o la gestione API per eseguire il deployment delle modifiche.

Verifica dell'applicazione dei criteri

Per verificare che un criterio venga applicato correttamente, l'API deve essere richiamata da un client HTTP. Per verificare questa configurazione della quota, invia più richieste all'API, superando il limite di quota impostato nel criterio della quota. Il percorso URI, configurato come impostazione del percorso di base in ProxyEndpoint, nella richiesta riportata di seguito è /weather).

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

Dopo aver inviato più di una richiesta in un minuto, dovresti visualizzare il seguente messaggio di errore message:

{  
   "fault":{  
      "faultstring":"policies.ratelimit.QuotaViolation",
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      }
   }
}

Questo indica che il criterio della quota viene applicato da API Services.

Gestione dei guasti basata sui criteri

Prendi nota del formato del messaggio di errore riportato sopra. Contiene una proprietà faultstring e una proprietà errorcode. In molti casi, devi implementare un comportamento per gestire questi errori. Ad esempio, potresti voler inviare un messaggio personalizzato a uno sviluppatore la cui app ha superato la quota.

Per ulteriori informazioni sulla gestione dei guasti, consulta Gestione dei guasti.

Best practice: insiemi di criteri comuni

Per soddisfare i requisiti di gestione di base, i proxy API in genere applicano i seguenti criteri:

Convalida di base della chiave API

Flusso di richiesta ProxyEndpoint:
  1. SpikeArrest
  2. XMLThreatProtection o JSONThreatProtection
  3. Convalida della chiave API
  4. Quota
  5. ResponseCache
Flusso di risposta ProxyEndpoint:
  1. ResponseCache

Trasformazione di base: da JSON a XML

Flusso di richiesta:
  1. SpikeArrest
  2. JSONThreatProtection
  3. Convalida della chiave API
  4. Quota
  5. JSONToXML
Flusso di risposta:
  1. XMLToJSON
  2. ResponseCache