Strumenti di sviluppo

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

In qualità di fornitore di servizi, sviluppi API per l'utilizzo da parte delle app client. Per creare, configurare, e gestire i proxy API e i prodotti API, puoi utilizzare l'UI o effettuare richieste HTTP alle API per accedere ai servizi RESTful, come descritto nelle sezioni seguenti.

Utilizzare l'UI Edge

L'UI Apigee Edge è uno strumento basato su browser che puoi utilizzare per creare, configurare e gestire proxy API e prodotti API. Un sottoinsieme di attività può essere eseguito solo utilizzando anche l'API,

La seguente tabella descrive come accedere all'UI Edge:

Prodotto Nome dell'UI URL di accesso
Edge UI Edge

Per accedere all'UI Edge, utilizza il seguente URL:

https://apigee.com/edge

Per un tutorial sull'utilizzo dell'UI Edge, consulta Creare il tuo primo proxy API.
Edge for Private Cloud UI Edge classica

Per accedere all'UI Edge per Edge for Private Cloud, utilizza il seguente URL:

http://ms-ip:9000

Dove ms-ip è l'indirizzo IP o il nome DNS del nodo del server di gestione.

Utilizzando l'UI Edge, puoi:

  • Creare proxy API modificando il codice e tracciando i flussi di richieste tramite i proxy.
  • Creare prodotti API che raggruppano i proxy per l'esposizione alle richieste dei client.
  • Gestire gli sviluppatori e le app per sviluppatori.
  • Configurare gli ambienti di test e di produzione.
  • Implementare applicazioni JavaScript e Node.js.

L'immagine seguente mostra l'editor del proxy API nell'UI che puoi utilizzare per creare e configurare un proxy API:

Mostra la scheda Sviluppa selezionata nell'editor del proxy API nell'UI Edge.

Utilizzare l'API Edge

Puoi utilizzare l'API Edge per gestire le risorse API. Le API forniscono anche l'accesso a funzionalità di basso livello che non sono esposte dall' UI.

Gli endpoint API spesso accettano dati contenenti informazioni di configurazione e richiedono di trasmettere 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 una qualsiasi delle risorse API.

Per un elenco completo delle API Apigee Edge, consulta il Riferimento API Apigee Edge.

Comprendere il percorso di base dell'API Edge

Il percorso che utilizzerai nelle richieste API concatena i seguenti elementi:

  • Un percorso di base che include il nome dell'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, chiama GET su:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis

Molte risorse sono limitate all'ambiente. Per impostazione predefinita vengono forniti due ambienti: test e produzione. Ad esempio, le cache sono limitate all'ambiente. Per impostazione predefinita, in ogni ambiente è inclusa una cache condivisa denominata "mycache" .

Puoi elencare le cache chiamando GET sulla risorsa della 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

Autenticare l'accesso

Quando chiami le API, devi autenticarti sul server API. Puoi farlo in uno dei seguenti modi:

Inoltre, Apigee consiglia di utilizzare l'autenticazione a due fattori, come descritto in Attivare l'autenticazione a due fattori per l'account Apigee.

Limiti dell'API Edge

Ogni organizzazione è limitata alle seguenti frequenze di chiamata dell'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 vengono conteggiati ai fini di 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.

Abbreviare gli URL delle richieste

Quando crei l'URL della richiesta alle API Edge, puoi utilizzare le seguenti abbreviazioni:

  • /e = /environments
  • /o = /organizations
  • /r = /revisions

Se utilizzi le abbreviazioni, devi utilizzarle in modo coerente. Ovvero, 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 genererà 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

Eseguire i comandi curl

Utilizza un client HTTP per effettuare 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.

Formattare le richieste e le risposte XML e JSON

Per impostazione predefinita, l'API Edge restituisce i dati in formato JSON. Per molte richieste, puoi ricevere la risposta in formato XML. Per farlo, imposta l'intestazione della richiesta Accept su application/xml, come mostrato 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 inviando la risposta tramite xmllint.

L'utilità acurl non supporta l'intestazione Accept. Di conseguenza, puoi ottenere 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 XML, puoi utilizzare xmllint:

curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -

Quando pubblichi o inserisci payload in XML, 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

Per impostazione predefinita, ogni organizzazione che utilizza Apigee Edge ha almeno due ambienti che può utilizzare per sviluppare, testare ed eseguire il deployment delle API: "test" e "prod". Utilizza l'ambiente "test" per sviluppare e testare le API prima di renderle disponibili pubblicamente. Solo gli sviluppatori interni possono accedere alle API di cui è stato eseguito il deployment nell'ambiente di test. Esegui il deployment delle API nell'ambiente "prod" 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 le intestazioni e i payload delle richieste e delle risposte, l'esecuzione delle policy, i valori delle variabili e gli eventuali errori che si sono verificati durante il flusso.

Punti dati chiave da utilizzare per la risoluzione dei problemi:

  • Timestamp: utilizza i timestamp per vedere quanto tempo impiega ogni passaggio per essere eseguito. Il confronto dei timestamp ti aiuta a isolare le policy che impiegano più tempo per essere eseguite e che rallentano le chiamate API.
  • Percorso di base: verificando il percorso di base, puoi assicurarti che una policy stia instradando il messaggio al server corretto.
  • Risultati dell'esecuzione delle policy: questi risultati ti 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:

Mostra la scheda Trace selezionata nell'editor del proxy API nell'UI Edge.

Ogni sessione di traccia è suddivisa nei seguenti passaggi principali:

  • Richiesta originale ricevuta dal client: mostra il verbo e il percorso URI di la richiesta dall'app client, le intestazioni, i dati del corpo e i parametri di query.
  • Richiesta inviata al servizio di backend: mostra il messaggio di richiesta inviato a al servizio di backend dal proxy API.
  • Risposta restituita dal servizio di backend: mostra le intestazioni e il payload della risposta restituiti dal servizio di backend.
  • Risposta finale inviata al client:il messaggio di risposta restituito all' app client richiedente una volta eseguito il flusso di risposta.