Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Le sezioni seguenti ti presentano i prodotti API e i concetti chiave correlati.
Che cos'è un prodotto API?
Come provider di API, crei prodotti API per raggruppare le tue API e renderle disponibili per l'utilizzo da parte degli sviluppatori di app. I prodotti API possono essere considerati alla stregua di linee di prodotti.
In particolare, un prodotto API raggruppa quanto segue:
- Raccolta di risorse API (URI)
- Piano di servizio
- Metadati specifici per la tua attività per il monitoraggio o l'analisi (facoltativo)
Le risorse 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 risolvere casi d'uso che soddisfano esigenze specifiche. Ad esempio, puoi creare un prodotto API che raggruppa una serie di risorse di mapping per consentire agli sviluppatori di integrare facilmente le mappe nelle loro applicazioni. Inoltre, puoi impostare proprietà diverse per ogni prodotto API, ad esempio livelli di prezzo diversi. Ad esempio, potresti 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 vantaggioso. Un secondo prodotto API che fornisce l'accesso alle stesse risorse, ma con un limite di accesso più elevato e un prezzo più alto.
- Un prodotto API senza costi che offre l'accesso di sola lettura alle risorse. Un secondo prodotto API che fornisce l'accesso in lettura/scrittura alle stesse risorse a un costo ridotto.
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 tue API. In Apigee, le chiavi API vengono fornite non per le API stesse, ma per i prodotti API. In altre parole, le chiavi API vengono fornite per i bundle di risorse con un piano di servizio allegato.
Gli sviluppatori di app accedono ai tuoi prodotti API registrando le loro app, come descritto in Registrare le 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 sia autorizzata ad accedere a una determinata risorsa API.
- L'app richiedente non abbia superato la quota consentita.
- Se definiti, gli ambiti OAuth definiti nel prodotto API corrispondano a quelli associati al token di 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, l'app deve essere associata ad almeno un prodotto API. In seguito all'associazione di un'app a uno o più prodotti API, Edge assegna all'app una chiave utente univoca.
La chiave utente o il token di accesso fungono da credenziali della richiesta. Lo sviluppatore di 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 derivato dalla chiave utente.
L'applicazione della chiave API non avviene automaticamente. Indipendentemente dall'utilizzo della chiave utente o dei token OAuth come credenziali della richiesta, il proxy API convalida le credenziali della richiesta nei proxy API includendo un criterio VerifyAPIKey o un criterio OAuth/VerifyAccessToken, nel flusso appropriato. Se non includi un criterio di applicazione delle credenziali nel tuo proxy API, qualsiasi chiamante può richiamare le tue API. Per ulteriori informazioni, consulta il criterio Verify API Key.
Per verificare le credenziali passate nella richiesta, Edge esegue i seguenti passaggi:
- Recupera le credenziali passate con la richiesta. Nel caso della verifica del token OAuth , Edge verifica che il token non sia scaduto e poi cerca la chiave consumer 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 se il percorso della risorsa corrente (percorso dell'URL) sia abilitato nel prodotto API.
- Verifica che la chiave utente non sia scaduta o revocata, che l'app non sia revocata, e che lo sviluppatore di app sia attivo.
Se tutti i controlli precedenti vengono superati, la verifica delle credenziali ha esito positivo.
In sintesi, Edge genera automaticamente le chiavi consumer, ma i publisher di API devono applicare il controllo delle chiavi nei proxy API utilizzando i criteri appropriati.
Approvazione automatica o manuale
Per impostazione predefinita, tutte le richieste per ottenere una chiave di accesso a un prodotto API da un'app vengono approvate automaticamente. In alternativa, puoi configurare il prodotto API in modo da approvare le chiavi manualmente. In questo caso, dovrai approvare le richieste di chiavi da qualsiasi app che aggiunge il prodotto API. Per ulteriori informazioni, consulta Registrare le app e gestire le chiavi API chiavi.
Quote
Le quote possono proteggere i server di backend dal traffico elevato e differenziare la tua 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ò aiutarti a proteggere i server dal sovraccarico se un prodotto è popolare e riceve una grande quantità di richieste.
Per informazioni sulla configurazione delle quote, consulta il criterio Quota. Per informazioni sull'utilizzo delle impostazioni delle quote dei prodotti nei criteri per le quote, consulta il seguente articolo della community How do the quota settings on an API product interact with quota policies in an API proxy?.
Ambiti OAuth
Come livello di sicurezza aggiuntivo, puoi definire tutti gli ambiti 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 devono corrispondere agli ambiti esistenti, altrimenti il prodotto non è sicuro.
Per ulteriori informazioni sull'utilizzo degli ambiti con i criteri OAuth di Edge, consulta Utilizzare gli ambiti OAuth 2.0.
Livelli di accesso
Quando definisci un prodotto API, puoi impostare i seguenti livelli di accesso.
| Livello di accesso | Descrizione |
|---|---|
| Pubblico | Prodotti API disponibili per tutti gli sviluppatori. Puoi aggiungerli ai portali per sviluppatori integrati o basati su Drupal. |
| Privato o solo interno | Prodotti API progettati per l'uso privato o interno. Nota: non esiste alcuna differenza funzionale tra i livelli di accesso Privato e Solo 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 interni 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 nel tuo portale per sviluppatori, come descritto nelle sezioni seguenti:
|