Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
Le seguenti sezioni introducono i prodotti API e i concetti chiave correlati.
Che cos'è un prodotto API?
In qualità di provider di API, puoi creare prodotti API per raggruppare le tue API e renderle disponibili per l'utilizzo agli sviluppatori di app. Puoi considerare i prodotti basati su API come la tua linea di prodotti.
In particolare, un prodotto API raggruppa quanto segue:
- Raccolta di risorse API (URI)
- Piano di servizio
- Metadati specifici della tua attività per il monitoraggio o l'analisi (facoltativi)
Le risorse delle API raggruppate in un prodotto API possono provenire da una o più API, quindi puoi combinare le risorse per creare set di funzionalità specializzati, come mostrato nella figura seguente.
Puoi creare più prodotti API per affrontare casi d'uso che soddisfano esigenze specifiche. Ad esempio, puoi creare un prodotto API che raggruppa una serie di risorse di mappatura per consentire agli sviluppatori di integrare facilmente le mappe nelle loro applicazioni. Inoltre, puoi impostare proprietà diverse su ciascun prodotto API, ad esempio livelli di prezzo diversi. Ad esempio, puoi offrire le seguenti combinazioni di prodotti API:
- Un prodotto API che offre un limite di accesso basso, ad esempio 1000 richieste al giorno, a un prezzo scontato. Un secondo prodotto API che fornisce l'accesso alle stesse risorse, ma con un limite di accesso e un prezzo più elevati.
- Un prodotto API senza costi che offre l'accesso in sola lettura alle risorse. Un secondo prodotto API che fornisce accesso in lettura/scrittura alle stesse risorse con un piccolo costo.
Inoltre, puoi controllare l'accesso alle risorse API in un prodotto API. Ad esempio, puoi raggruppare le risorse a cui possono accedere solo gli sviluppatori interni o solo i clienti paganti.
I prodotti API sono il meccanismo centrale per l'autorizzazione e il controllo dell'accesso alle API. In Apigee, viene eseguito il provisioning delle chiavi API non per le API stesse, ma per i prodotti basati su API. In altre parole, viene eseguito il provisioning delle chiavi API per pacchetti di risorse a cui è associato un piano di servizio.
Gli sviluppatori di app accedono ai prodotti API registrando le proprie app, come descritto nella sezione Registrazione delle app. Quando un'app tenta di accedere a un prodotto API, l'autorizzazione viene applicata da Apigee in fase di runtime per garantire che:
- L'app richiedente può accedere a una determinata risorsa API.
- L'app richiedente non ha superato la quota consentita.
- Se definiti, gli ambiti OAuth definiti nel prodotto API corrispondono a quelli associati al token di accesso presentato dall'app.
Comprendere i concetti chiave
Esamina i seguenti concetti chiave prima di creare i prodotti basati su API.
Chiavi API
Quando registri l'app di uno sviluppatore nella tua organizzazione, l'app deve essere associata ad almeno un prodotto API. Dopo aver accoppiato un'app con uno o più prodotti basati su API, Edge assegna all'app una chiave utente univoca.
La chiave utente o il token di accesso fungono da credenziali di richiesta. Lo sviluppatore dell'app incorpora la chiave utente nell'app in modo che, quando l'app effettua una richiesta a un'API ospitata da Edge, l'app passi 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. Sia che utilizzi la chiave utente o i token OAuth come credenziali di richiesta, il proxy API convalida le credenziali della richiesta nei proxy API includendo un criterio VerificationAPIKey o un criterio OAuth/VerifyAccessToken nel flusso appropriato. Se non includi un criterio di applicazione delle credenziali nel proxy API, qualsiasi chiamante può richiamare le tue API. Per maggiori informazioni, consulta la pagina Verificare il criterio della chiave API.
Per verificare le credenziali passate nella richiesta, Edge esegue i seguenti passaggi:
- Recupera le credenziali trasmesse con la richiesta. Nel caso della verifica del token OAuth, Edge verifica che il token non sia scaduto, quindi cerca la chiave utente utilizzata per generare il token.
- Recupera l'elenco dei prodotti API a cui è stata associata la chiave utente.
- Verifica che il proxy API corrente sia incluso nel prodotto API e che il percorso della risorsa (percorso dell'URL) attuale sia abilitato nel prodotto API.
- Verifica che la chiave utente non sia scaduta o revocata, che l'app non sia stata revocata e che lo sviluppatore dell'app sia attivo.
Se tutti i controlli precedenti vengono superati, la verifica delle credenziali ha esito positivo.
In conclusione, Edge genera automaticamente chiavi consumer, ma i publisher di API devono applicare il controllo delle chiavi nei proxy API utilizzando criteri appropriati.
Approvazione automatica e manuale
Per impostazione predefinita, tutte le richieste di ottenere una chiave per accedere a un prodotto API da un'app vengono approvate automaticamente. In alternativa, puoi configurare il prodotto API per l'approvazione manuale delle chiavi. In questo caso, dovrai approvare le richieste di chiavi da qualsiasi app che aggiunge il prodotto API. Per maggiori informazioni, consulta la sezione Registrare app e gestire le chiavi API.
Quote
Le quote possono proteggere i server di backend dal traffico elevato e differenziare la linea di prodotti. Ad esempio, potresti voler raggruppare le risorse con una quota elevata come prodotto premium e utilizzare lo stesso bundle con una quota inferiore come prodotto di base. Una quota può aiutare a proteggere i tuoi server dal sovraccarico se un prodotto è molto popolare e riceve una grande quantità di richieste.
Per informazioni sulla configurazione delle quote, consulta i criteri per le quote. Per informazioni sull'utilizzo delle impostazioni delle quote per i prodotti nei criteri per le quote, consulta il seguente articolo della community In che modo le impostazioni delle quote in un prodotto API interagiscono con i criteri per le quote in un proxy API?.
Ambiti OAuth
Come ulteriore livello di sicurezza, puoi definire qualsiasi ambito OAuth, come elenco separato da virgole, che deve essere presente nei token di accesso inviati tramite il prodotto. Quando crei un prodotto, devi conoscere tutti gli ambiti utilizzati dalla tua organizzazione. Gli ambiti aggiunti a un prodotto devono corrispondere a quelli esistenti oppure il prodotto non è sicuro.
Per saperne di più sull'utilizzo degli ambiti con i criteri OAuth2 di Edge, consulta l'articolo sull'utilizzo degli ambiti OAuth2.
Livelli di accesso
Quando definisci un prodotto API, puoi impostare i seguenti livelli di accesso.
| Livello di accesso | Descrizione |
|---|---|
| Pubblico | Prodotti basati su API disponibili per tutti gli sviluppatori. Puoi aggiungerli a portali per sviluppatori integrati o basati su Drupal. |
| Privato o solo interno | Prodotti basati su API progettati per uso privato o interno. Nota:non esiste una differenza funzionale tra i livelli di accesso Privato e Solo per uso interno. Scegli l'etichetta che descrive meglio il pubblico di destinazione del prodotto API. Per il portale integrato, puoi aggiungere prodotti API privati o solo per uso interno e renderli disponibili agli sviluppatori di app, se necessario. Per i portali per sviluppatori basati su Drupal, puoi gestire l'accesso ai prodotti API privati o solo interni sul tuo portale per gli sviluppatori, come descritto nelle seguenti sezioni:
|