Introduzione ai prodotti basati su API

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza documentazione di Apigee Edge.

Le seguenti sezioni introducono i prodotti API e i concetti correlati come quote e chiavi API.

Che cos'è un prodotto API?

In qualità di provider di API, puoi creare prodotti basati su API per raggruppare le tue API e renderle disponibili per le app per il consumo. I prodotti basati su API possono essere considerati come una linea di prodotti.

Nello specifico, un prodotto API raggruppa una o più operazioni. Un'operazione specifica un proxy API e i percorsi delle risorse accessibili su quel proxy. Un'operazione può anche limitare l'accesso con metodi HTTP e quota.

I prodotti basati su API sono il meccanismo centrale per il controllo dell'accesso alle API. definendo una o più API in un'app per sviluppatori, possono limitare l'accesso ai proxy con una chiave API. In Apigee, le chiavi API vengono non per le API, ma per i prodotti basati su API. In altre parole, le chiavi API per pacchetti di operazioni che definiscono una linea di prodotti o un piano di servizio specifico.

Casi d'uso comuni

Puoi creare più prodotti API che contengono operazioni per gestire casi d'uso specifici. Ad esempio, puoi creare un prodotto API che raggruppa una serie di operazioni che contengono risorse di mappatura per consentire agli sviluppatori di integrare facilmente le mappe nelle loro applicazioni.

Inoltre, puoi utilizzare i prodotti basati su API per definire i livelli di prezzo in base a criteri quali:

Il numero di richieste:

  • Premium: richieste illimitate al giorno
  • Base: fino a 1000 richieste al giorno
  • Gratuito: fino a 100 richieste al giorno

O livello di accesso:

  • Premium: lettura, scrittura, aggiornamento ed eliminazione
  • Base: lettura e aggiornamento
  • Gratuita: sola lettura

O una qualsiasi combinazione di questi elementi:

  • Premium extra: leggi e scrivi un numero illimitato di volte al giorno
  • Premium: lettura e scrittura fino a 1000 richieste al giorno
  • Base: accesso in lettura e scrittura fino a 100 volte al giorno
  • Gratuito: leggi fino a 1000 volte al giorno
  • Gratuito: accesso di sola lettura limitato a 100 richieste al giorno

Requisiti

I prodotti basati su API che fanno parte del pagamento a consumo devono includere:

Operazioni

Un'operazione è un gruppo di attributi che limitano l'accesso a uno o più proxy API in base su criteri come percorso della risorsa, metodo HTTP e quota. Un'operazione include i seguenti attributi:

Attributo Obbligatorio? Descrizione
proxy API Obbligatorio Ogni gruppo operazioni deve specificare un proxy API. È consentito un solo proxy per operazione gruppo.
Servizio remoto Dipende Necessario solo se installi e prevedi di utilizzare Apigee Adapter for Envoy.
Percorso della risorsa Obbligatorio Ogni gruppo di operazioni deve specificare uno o più percorsi di risorse. Percorsi delle risorse in un'operazione limitare l'accesso a risorse specifiche su un proxy API. (un percorso della risorsa è la parte un URL di richiesta del proxy API che segue il percorso di base del proxy).
Metodo HTTP Facoltativo Puoi anche limitare l'accesso a un proxy utilizzando il metodo HTTP. Ad esempio, se specifichi GET e POST per un gruppo di operazioni, quindi solo HTTP GET e Le richieste POST possono accedere al proxy per il percorso della risorsa specificato. Se non è disponibile alcun metodo , allora sono consentiti tutti i metodi.
Quota Facoltativo Puoi specificare una quota per il gruppo di operazioni. La quota specificata in un gruppo di operazioni ha la precedenza su una quota a livello di prodotto API, se specificata.
Attributi personalizzati Facoltativo Gli attributi personalizzati sono utili per le metriche, il monitoraggio o i casi in cui vuoi archiviare informazioni aggiuntive con un prodotto API a cui è possibile accedere o che è possibile recuperarle in un secondo momento. Personalizzate esistono attributi associati a un'operazione in aggiunta a qualsiasi altra API personalizzata a livello di prodotto ed è accessibile in runtime come variabili di flusso con il prefisso apiproduct.operation.attributes.

Chiavi API

Quando registri l'app di uno sviluppatore nella tua organizzazione, questa deve essere associata a almeno un prodotto API. Come risultato dell'accoppiamento di un'app con uno o più prodotti basati su API, Apigee assegna all'app una chiave utente univoca. Vedi anche Controllo dell'accesso alle API registrando le app.

La chiave utente o il token di accesso fungono da credenziali di richiesta. Lo sviluppatore dell'app incorpora chiave utente nell'app, in modo che quando quest'ultima invia una richiesta a un'API ospitata da Apigee, l'app trasmette la chiave utente nella richiesta in uno dei seguenti modi:

  • Quando l'API utilizza la verifica della chiave API, l'app deve passare direttamente la chiave utente.
  • Quando l'API utilizza la verifica del token OAuth, l'app deve passare un token che è stato derivato. dalla chiave utente.

L'applicazione delle chiavi API non avviene automaticamente. Se utilizzare la chiave utente o i token OAuth come credenziali di richiesta, il proxy API convalida le credenziali di richiesta nei proxy API includendo un criterioVerifyAPIKey o una configurazione di criteri VerifyAccessToken (vedi criterio OAuthv2) nel flusso appropriato. Se non includi un'applicazione delle credenziali nel proxy API, qualsiasi chiamante può richiamare le tue API.

Per verificare le credenziali trasmesse nella richiesta, Apigee esegue questi passaggi:

  1. Recupera le credenziali passate con la richiesta. Nel caso della verifica del token OAuth, Apigee verifica che il token non sia scaduto e quindi cerca la chiave consumer utilizzata per generare il token.
  2. Recupera l'elenco dei prodotti API a cui è stata associata la chiave utente.
  3. Conferma che il proxy API corrente sia incluso nel prodotto API, se il percorso della risorsa attuale (URL path) è abilitato sul prodotto API e, se incluso nel prodotto, utilizzato dalla richiesta un verbo HTTP specificato.
  4. Verifica che la quota, se specificata, non sia stata superata.
  5. Verifica che la chiave utente non sia scaduta o revocata, che l'app non sia stata revocata e verifica che lo sviluppatore dell'app sia attivo.

Se tutti i controlli precedenti vengono superati, la verifica delle credenziali ha esito positivo.

In breve, Apigee genera automaticamente chiavi consumer, ma gli editori di API devono applicare il controllo delle chiavi nei proxy API usando criteri appropriati.

Approvazione chiave

Per impostazione predefinita, tutte le richieste per ottenere una chiave per accedere a un prodotto API da un'app vengono automaticamente approvato. In alternativa, puoi configurare il prodotto API in modo da dover approvare le chiavi manualmente. L'impostazione viene descritta in Gestione dei prodotti API. In questo caso, dovrai approvare le richieste chiave da qualsiasi app che aggiunge il prodotto API. Per ulteriori informazioni, vedi Controllo dell'accesso alle API registrando le app.

Quote

Le quote possono proteggere i server di backend da alte variazioni di traffico e differenziare linea di prodotti. Ad esempio, puoi raggruppare risorse con una quota elevata come prodotti premium, e utilizzare lo stesso bundle con una quota inferiore come prodotto di base. Le quote possono aiutarti a proteggere i server non siano sovraccarichi se un prodotto è popolare e riceve una grande quantità di richieste in poco tempo.

Puoi specificare una quota valida per tutti i proxy API inclusi nel prodotto API. le quote a livello di operazione. Una quota specificata in un'operazione ha la precedenza su una quota impostata a livello di prodotto API.

L'impostazione di limiti di quota su un prodotto API non automaticamente la quota. È semplicemente un limite predefinito a cui si può fare riferimento nei criteri per le quote. Ecco alcuni vantaggi dell'impostazione di una quota sul prodotto a cui far riferimento i criteri di quota:

  • Utilizza un criterio per le quote per applicare un'impostazione uniforme a tutti i proxy API in un prodotto API.
  • Se modifichi le impostazioni delle quote del prodotto API in fase di runtime, i criteri per le quote verranno impostati automaticamente fare riferimento alle impostazioni di quota aggiornate.

Per ulteriori informazioni, consulta le seguenti risorse:

ambiti OAuth

Puoi definire gli ambiti OAuth come elenchi separati da virgole che devono essere presenti nei token di accesso associati al prodotto. Per saperne di più sull'utilizzo degli ambiti con Apigee OAuth consulta la sezione Utilizzo Ambiti OAuth2.

Livelli di accesso

Quando si definisce un prodotto API, è possibile impostare i seguenti livelli di accesso:

Livello di accesso Descrizione
Public Prodotti basati su API disponibili per tutti gli sviluppatori. Puoi aggiungerli alle app integrate Portali per gli sviluppatori basati su Drupal.
Private o Internal only Prodotti basati su API progettati per l'uso privato o interno.

Per il portale integrato, puoi aggiungere Private o Internal only prodotti basati su API e rendili disponibili agli sviluppatori di app, come richiesto.

Per i portali per sviluppatori basati su Drupal, puoi gestire l'accesso a Private o Internal only prodotti API sul portale per gli sviluppatori, come descritto di seguito sezioni:

  • Per i portali per sviluppatori di Drupal 10, puoi configurare l'accesso a Private o Internal only prodotti API sul portale per gli sviluppatori, come descritto in Configura le autorizzazioni di accesso ai prodotti API.

  • Per i portali per sviluppatori di Drupal 7, non puoi aggiungere prodotti API Private o Internal only a il tuo portale per gli sviluppatori.

    Rendere disponibili nell'app i prodotti API Private o Internal only sviluppatori, devi aggiungerli manualmente a un'app registrata dalla UI o dall'API Apigee, come descritto in Controllo dell'accesso alle API mediante la registrazione delle app.

    Dopo l'aggiunta, lo sviluppatore vedrà nel tuo portale il prodotto API associato all'app. come descritto in Gestire i prodotti API in un'app. Se lo sviluppatore dell'app disattiva accesso a un prodotto API Private o Internal only, il prodotto API viene rimosso dall'app e deve essere aggiunto di nuovo manualmente dal portale amministratore.