Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
In qualità di fornitore di servizi, sviluppi API per l'utilizzo da parte delle app client. Per creare, configurare e gestire proxy API e prodotti API, puoi utilizzare l'interfaccia utente o inviare richieste HTTP alle API per accedere ai servizi RESTful, come descritto nelle sezioni seguenti.
Utilizzare l'UI Edge
L'UI di Apigee Edge è uno strumento basato su browser che puoi utilizzare per creare, configurare e gestire proxy API e prodotti API. Anche un sottoinsieme di attività può essere eseguito solo utilizzando l'API.
La tabella seguente descrive come accedere all'interfaccia utente Edge:
Prodotto | Nome UI | URL di accesso |
---|---|---|
Perimetrale | UI perimetrale | Per accedere all'interfaccia utente Edge, utilizza il seguente URL: https://apigee.com/edge Per un tutorial sull'utilizzo della UI Edge, consulta Creare il tuo primo proxy API. |
Edge per cloud privato | UI di Edge versione classica | Per accedere all'UI Edge per Edge per il cloud privato, utilizza il seguente URL: http://ms-ip:9000 Dove ms-ip è l'indirizzo IP o il nome DNS del nodo del server di gestione. |
Con l'interfaccia utente Edge, puoi:
- Crea proxy API modificando il codice e tracciando i flussi di richieste attraverso i proxy.
- Crea prodotti API che raggruppano i proxy per l'esposizione alle richieste del client.
- Gestire le app per sviluppatori e sviluppatori.
- Configura gli ambienti di test e produzione.
- Implementa le applicazioni JavaScript e Node.js.
L'immagine seguente mostra l'editor proxy API nella UI, che puoi utilizzare per creare e configurare un proxy API:
Utilizzare l'API Edge
Puoi utilizzare l'API Edge per gestire le risorse dell'API. Le API forniscono inoltre l'accesso a funzionalità di basso livello che non sono esposte dalla UI.
Gli endpoint API spesso accettano dati contenenti informazioni di configurazione e richiedono che l'utente passi le informazioni di autenticazione, come nome utente e password, per accedervi. Seguendo i principi RESTful, puoi chiamare i metodi HTTP GET
, POST
, PUT
e DELETE
su qualsiasi risorsa dell'API.
Per un elenco completo delle API Apigee Edge, consulta il riferimento per le API Apigee Edge.
Informazioni sul percorso di base dell'API Edge
Il percorso che utilizzerai nelle richieste API concatena quanto segue:
- Un percorso di base che include il nome della tua organizzazione. Ad esempio:
https://api.enterprise.apigee.com/v1/organizations/org_name
- Un endpoint che rimanda alla risorsa Edge a cui stai accedendo.
Ad esempio, se il nome della tua organizzazione è apibuilders
, ogni chiamata che effettui all'API utilizzerà il seguente percorso di base:
https://api.enterprise.apigee.com/v1/organizations/apibuilders
Per recuperare un elenco di proxy API nella tua organizzazione, devi chiamare GET su:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis
Molte risorse hanno come ambito l'ambiente. Per impostazione predefinita, vengono forniti due ambienti: test e produzione. Ad esempio, l'ambito delle cache è definito per ambiente. Una cache condivisa denominata "mycache" è inclusa per impostazione predefinita in ogni ambiente.
Puoi elencare le cache richiamando GET sulla risorsa di cache come segue:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches
Autentica l'accesso
Devi autenticarti con il server API quando chiami le API. Puoi farlo in uno dei seguenti modi:
- OAuth2
- SAML
- Autorizzazione di base (non consigliata)
Inoltre, Apigee consiglia di utilizzare l'autenticazione a due fattori, come descritto in Abilitare l'autenticazione a due fattori per il tuo account Apigee.
Limiti dell'API Edge
Ogni organizzazione è limitata alle seguenti tariffe di chiamate API Edge:
- 10.000 chiamate al minuto per le organizzazioni con piani a pagamento
- 600 chiamate al minuto per le organizzazioni di prova
I codici di stato HTTP 401
e 403
non incidono su questo limite. Tutte le chiamate che superano questi limiti restituiscono un codice di stato 429 Too Many Requests
.
Suggerimenti per l'utilizzo delle API Edge
Questa sezione descrive alcune tecniche che semplificano l'utilizzo delle API Edge.
Abbreviazione degli URL delle richieste
Quando crei l'URL della richiesta per le API Edge, puoi utilizzare le seguenti abbreviazioni:
/e = /environments
/o = /organizations
/r = /revisions
Se usa le abbreviazioni, deve usarle in modo coerente. Vale a dire, abbrevia tutti gli elementi nel percorso, come indicato sopra e illustrato nell'esempio seguente, oppure nessuno. L'utilizzo di elementi completi e abbreviati nello stesso percorso causerà un errore.
Ad esempio:
THIS: https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/environments/prod/apis/helloworld/revisions/1/deployments CAN BE MUCH SHORTER: https://api.enterprise.apigee.com/v1/o/ahamilton-eval/e/prod/apis/helloworld/r/1/deployments
Esegui i comandi curl
Utilizza un client HTTP per inviare richieste all'API. Molti esempi nella documentazione forniscono richieste API di esempio utilizzando curl
, un client HTTP ampiamente utilizzato. Se devi installare curl
, puoi scaricarlo da http://curl.haxx.se.
Le chiamate all'API supportano la compressione gzip sulle risposte. Se imposti 'Accept-Encoding: gzip, deflate'
nelle chiamate API, qualsiasi risposta superiore a 1024 byte viene restituita in formato gzip.
Formattazione di richieste e risposte XML e JSON
L'API Edge restituisce i dati come JSON per impostazione predefinita. Per molte richieste, puoi invece ricevere la risposta in formato XML. A questo scopo, imposta l'intestazione della richiesta Accept
su
application/xml
, come illustrato nell'esempio seguente:
curl -H "Authorization: Bearer `get_token`" \ -H "Accept: application/xml" \ https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \ | xmllint --format -
La risposta dovrebbe essere simile alla seguente:
<List> <Item>SOAP-Message-Validation-1</Item> <Item>Spike-Arrest-1</Item> <Item>XML-to-JSON-1</Item> </List>
Tieni presente che questo esempio utilizza prettyprint
per visualizzare i risultati inserendo la risposta tramite xmllint
.
L'utilità acurl
non supporta l'intestazione Accept
. Di conseguenza, puoi ricevere risposte in formato JSON solo con acurl
.
Per utilizzare prettyprint
per una risposta JSON, puoi utilizzare la libreria Python json.tool
:
curl https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \ -H "Accept: application/json" \ -H "Authorization: Bearer `get_token`" \ | python -m json.tool
Di seguito è riportato un esempio della risposta:
[ "SOAP-Message-Validation-1", "Spike-Arrest-1", "XML-to-JSON-1" ]
Per il formato XML, puoi utilizzare xmllint
:
curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -
Quando invii payload in XML o POST, utilizza l'intestazione HTTP Content-type
:
acurl -H "Content-type:text/xml" -X POST -d \ '<XMLPayload> </XMLPayload> ' \ https://api.enterprise.apigee.com/v1/organizations/apifactory/apis -u email_address
Ambienti di deployment
Ogni organizzazione che utilizza Apigee Edge per impostazione predefinita, dispone di almeno due ambienti da utilizzare per sviluppare, testare ed eseguire il deployment delle API: "test" e "prod". Utilizza l'ambiente "di test" per sviluppare e testare le tue API prima di renderle disponibili pubblicamente. Solo i tuoi sviluppatori interni possono accedere alle API di cui è stato eseguito il deployment nell'ambiente di test. Esegui il deployment delle tue API nell'ambiente di produzione per renderle pubblicamente disponibili agli sviluppatori di app.
Debug e test
Apigee fornisce uno strumento di traccia che ti consente di eseguire il debug dei flussi di richieste e risposte end-to-end. I risultati della traccia mostrano intestazioni e payload di richiesta e risposta, l'esecuzione dei criteri, i valori delle variabili ed eventuali errori che potrebbero essersi verificati durante il flusso.
Punti dati chiave da utilizzare per la risoluzione dei problemi:
- Timestamp: utilizza i timestamp per vedere quanto tempo richiede l'esecuzione di ogni passaggio. Il confronto dei timestamp ti aiuta a isolare i criteri che richiedono più tempo per l'esecuzione e rallentano le chiamate API.
- Percorso base: verificando il percorso di base, puoi assicurarti che un criterio instrada il messaggio al server corretto.
- Risultati dell'esecuzione dei criteri: questi risultati consentono di verificare se il messaggio viene modificato come previsto, ad esempio se viene trasformato da XML a JSON o se viene memorizzato nella cache.
La figura seguente mostra i risultati della traccia:
Ogni sessione di Trace è suddivisa nei seguenti passaggi principali:
- Richiesta originale ricevuta dal client: mostra il percorso verbale e URI della richiesta proveniente dall'app client, le intestazioni, i dati del corpo e i parametri di query.
- Richiesta inviata al tuo servizio di backend: mostra il messaggio di richiesta inviato al servizio di backend dal proxy API.
- Risposta restituita dal servizio di backend: mostra le intestazioni della risposta e il payload restituiti dal servizio di backend.
- Risposta finale inviata al client: il messaggio di risposta è stato restituito all'app client del richiedente dopo l'esecuzione del flusso di risposta.