Che cos'è un criterio?

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

Apigee Edge consente di "programmare" il comportamento dell'API senza scrivere alcun 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 tipi comuni di funzionalità di gestione a un'API in modo facile e affidabile. I criteri offrono funzionalità come sicurezza, limitazione della frequenza, trasformazione e mediazione, evitandoti di dover programmare e gestire questa funzionalità in autonomia.

Non devi limitarti all'insieme di tipi di criteri forniti da Apigee Edge. Puoi anche scrivere script e codice personalizzati (come applicazioni JavaScript e Node.js) che estendono la funzionalità proxy API e ti consentono di innovare oltre alle funzionalità di gestione di base supportate dai criteri di Apigee.

Guarda questo video per un'introduzione all'allegato delle norme e alla relativa applicazione.

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 dimestichezza con gli strumenti XML, ti consigliamo di acquisire familiarità con gli schemi dei criteri negli esempi di piattaforme API su GitHub.

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

Gestione del traffico

I criteri nella categoria di gestione del traffico consentono di controllare il flusso dei messaggi di richiesta e risposta tramite un proxy API. Questi criteri supportano il controllo sia a livello operativo che aziendale. Offrono il controllo sulla velocità effettiva non elaborata e possono anche controllare il traffico in base alle singole 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 della categoria sicurezza supportano l'autenticazione, l'autorizzazione e la sicurezza basata sui contenuti.

Mediazione

I criteri nella categoria di mediazione ti consentono di manipolare attivamente i messaggi mentre passano attraverso 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 dei messaggi in uscita. I criteri di mediazione interagiscono anche con i servizi di base esposti dai servizi API, consentendoti di recuperare dati su app, sviluppatori, token di sicurezza e prodotti API in fase di runtime.

Estensione

I criteri nella categoria di estensioni ti consentono di sfruttare l'estensibilità dei servizi API per implementare un comportamento personalizzato nel linguaggio di programmazione che preferisci.

Ogni tipo di norma è documentato in dettaglio nella panoramica dei riferimenti alle norme. Questo argomento illustra l'interazione generale e mostra come creare criteri e come collegarli ai flussi in una configurazione 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 collegato un criterio o apportato modifiche a un criterio esistente, utilizza l'interfaccia utente o l'API di gestione per eseguire il deployment delle modifiche.

Verificare l'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 della quota impostato nei criteri per le quote. (Il percorso URI, configurato come impostazione del percorso di base in ProxyEndpoint, nella richiesta seguente è /weather).

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

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

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

Questo indica che il criterio per le quote è applicato dai servizi API.

Gestione degli errori basata su criteri

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

Per ulteriori informazioni sulla gestione degli errori, consulta la sezione Gestione degli errori.

Best practice: serie di criteri comuni

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

Convalida delle chiavi API di base

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

Trasformazione di base: da JSON a XML

Flusso di richieste:
  1. SpikeArrest
  2. JSONThreatProtection
  3. Convalida delle chiavi API
  4. Quota
  5. JSONToXML
Flusso di risposta:
  1. XMLToJSON
  2. ResponseCache