Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione
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 basati su API per raggruppare le tue API e renderle disponibili per il consumo da parte degli sviluppatori di app. I prodotti basati su API possono essere considerati come una linea di prodotti.
In particolare, un prodotto API raggruppa i seguenti dati:
- Raccolta di risorse API (URI)
- Piano di servizio
- (Facoltativo) Metadati specifici per la tua attività per il monitoraggio o l'analisi
Le risorse API in bundle in un prodotto API possono provenire da una o più API, quindi puoi combinare per creare set di caratteristiche specializzate, come mostrato nella figura seguente.
Puoi creare più prodotti API per soddisfare casi d'uso che risolvono esigenze specifiche. Ad esempio, puoi creare un prodotto API che raggruppa una serie di risorse di mappatura consentono agli sviluppatori di integrare facilmente le mappe nelle loro applicazioni. Inoltre, puoi impostare proprietà diverse per ciascun prodotto API, ad esempio prezzi diversi 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 accesso alle stesse risorse, ma con un limite di accesso più elevato e un prezzo più elevato.
- Un prodotto API senza costi che offre accesso in sola lettura alle risorse. Un secondo prodotto API che fornisce accesso in lettura/scrittura alle stesse risorse a un piccolo costo.
Inoltre, puoi controllare l'accesso alle risorse API in un prodotto API. Ad esempio, puoi raggruppare risorse a cui possono accedere solo gli sviluppatori interni o solo i clienti paganti.
I prodotti basati su 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 API. In altre parole, API viene eseguito il provisioning delle chiavi per bundle di risorse a cui è associato un piano di servizio.
Gli sviluppatori di app possono accedere ai prodotti API registrando le loro 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 è autorizzata ad 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 all'accesso presentato dall'app.
Comprendere i concetti chiave
Esamina i seguenti concetti chiave prima di creare i tuoi prodotti API.
Chiavi API
Quando registri l'app di uno sviluppatore nella tua organizzazione, questa deve essere associata ad almeno un prodotto API. Come risultato dell'accoppiamento di un'app con uno o più prodotti API, Edge assegna all'app una chiave utente univoca.
La chiave utente o il token di accesso fungono da credenziali di richiesta. Lo sviluppatore di app incorpora la chiave utente nell'app in modo che quando quest'ultima effettua una richiesta a un'API ospitata da Edge, l'app passa 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 trasmettere un token 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 nel tuo Proxy API includendo un criterioVerifyAPIKey o un criterio OAuth/VerifyAccessToken. nel flusso appropriato. Se non includi un criterio di applicazione delle credenziali nel tuo un proxy API, qualsiasi chiamante può richiamare le tue API. Per ulteriori informazioni, consulta il criterio Verifica della chiave API.
Per verificare le credenziali trasmesse nella richiesta, Edge esegue questi passaggi:
- Recupera le credenziali passate con la richiesta. Nel caso di OAuth verifica del token, Edge verifica che il token non sia scaduto e poi cerca 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 l'attuale il percorso della risorsa (percorso URL) è abilitato nel prodotto API.
- 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, Edge genera automaticamente le chiavi consumer, ma gli editori delle API devono applicare il controllo delle chiavi nei proxy API usando criteri appropriati.
Confronto tra automatico e manuale approvazione
Per impostazione predefinita, tutte le richieste per ottenere una chiave per accedere a un prodotto API da un'app vengono approvate automaticamente. In alternativa, puoi configurare il prodotto API per approvare manualmente le chiavi. In questo caso, dovrai approvare le richieste chiave di qualsiasi app che aggiunge il prodotto API. Per ulteriori informazioni, vedi Registrare app e gestire l'API. chiave.
Quote
Le quote consentono di proteggere i server di backend dal traffico elevato e differenziare la linea di prodotti. Ad esempio, potresti voler raggruppare risorse con una quota elevata come prodotto premium e utilizzare lo stesso bundle con una quota inferiore rispetto a un prodotto di base. Una quota può contribuire a proteggere i server essere sopraffatto se un prodotto è popolare e riceve un numero elevato di richieste.
Per informazioni sulla configurazione della quota, consulta i criteri per le quote. Per informazioni su sull'utilizzo delle impostazioni di quota dei prodotti nei criteri di quota, consulta il seguente articolo della community Come interagiscono le impostazioni della quota su un prodotto API 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 devono essere presenti nei token di accesso inviati tramite il prodotto. Quando crei un prodotto, devi conoscere tutti gli ambiti utilizzati dalla tua organizzazione. Gli ambiti che aggiungi a un prodotto deve corrispondere agli ambiti esistenti o il prodotto non è sicuro.
Per saperne di più sull'utilizzo degli ambiti con i criteri OAuth di Edge, vedi Utilizzo degli ambiti OAuth2.
Livelli di accesso
Quando si definisce un prodotto API, è possibile impostare i livelli di accesso riportati di seguito.
| 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. |
| Solo per uso interno o privato | Prodotti basati su API progettati per l'uso privato o interno. Nota: non esiste alcuna differenza funzionale tra il livello di accesso privato e quello interno. Scegli l'etichetta che descrive meglio il pubblico di destinazione del prodotto API. Per il portale integrato, puoi aggiungere prodotti API privati o interni e renderli disponibili agli sviluppatori di app, come richiesto. Per i portali per sviluppatori basati su Drupal, puoi gestire l'accesso ai prodotti API solo per uso interno o privato sul tuo portale per sviluppatori, come descritto nelle seguenti sezioni:
|