Strumenti di sviluppo

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

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

Utilizzare l'UI Edge

La UI di 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 l'API, .

La tabella seguente descrive come accedere alla UI Edge:

Prodotto Nome UI URL di accesso
Edge UI Edge

Per accedere alla UI Edge, usa l'URL seguente:

https://apigee.com/edge

Per un tutorial sull'uso della UI Edge, vedi Crea il tuo primo proxy API.
Edge per cloud privato UI classica di Edge

Per accedere all'interfaccia utente Edge per Edge per 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.

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 proxy per l'esposizione alle richieste del client.
  • Gestisci sviluppatori e app per sviluppatori.
  • Configura i tuoi ambienti di test e produzione.
  • Implementare applicazioni JavaScript e Node.js.

L'immagine seguente mostra l'editor proxy API nell'interfaccia utente, che puoi utilizzare per creare e configurare un'istanza Proxy API:

Mostra la scheda Sviluppo selezionata nell'editor proxy API nella UI Edge.

Utilizzare l'API Edge

Puoi utilizzare l'API Edge per gestire le risorse API. Le API forniscono inoltre accesso a funzionalità di basso livello che non sono esposte ai nell'interfaccia utente.

Gli endpoint API spesso prendono dati contenenti informazioni di configurazione e richiedono passare informazioni di autenticazione, come nome utente e password, per accedervi. Dopo RESTful puoi chiamare 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.

Informazioni sulla base dell'API Edge percorso

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 punta alla risorsa Edge a cui stai accedendo.

Ad esempio, se il nome della tua organizzazione è apibuilders, ogni chiamata che effettui al L'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

L'ambito di molte risorse è definito dall'ambiente. Per impostazione predefinita sono forniti due ambienti: test e prod. Ad esempio, l'ambito delle cache è limitato all'ambiente. Una cache condivisa denominata "mycache" è incluso per impostazione predefinita in ogni ambiente.

Puoi elencare le cache chiamando GET sulla risorsa cache in questo modo:

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

Quando chiami le API, devi autenticarti al server API. Cosa puoi fare in uno dei seguenti modi:

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

Limiti API Edge

Ogni organizzazione è limitata alle seguenti tariffe di chiamata all'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 in questo limite. Le chiamate che superano questi 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 è più facile.

Abbreviazione degli URL delle richieste

Quando crei l'URL della richiesta alle API Edge, puoi utilizzare quanto segue abbreviazioni:

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

Se usi le abbreviazioni, devi usarle in modo coerente. Abbrevia tutti gli elementi nel come indicato sopra e illustrato nel seguente esempio, oppure nessuno. L'utilizzo di elementi completi e abbreviati nello stesso percorso comporterà 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 comandi curl

Utilizzare un client HTTP per effettuare richieste all'API. Molti esempi nella documentazione fornire richieste API di esempio utilizzando curl, un client HTTP molto diffuso. Per installa curl, puoi scaricarla da http://curl.haxx.se.

Le chiamate all'API supportano la compressione gzip diverse. Se imposti 'Accept-Encoding: gzip, deflate' nelle chiamate API, qualsiasi una risposta maggiore di 1024 byte viene restituita in formato gzip.

Formattazione di richieste e risposte XML e JSON

L'API Edge restituisce i dati in formato JSON per impostazione predefinita. Per molte richieste, puoi ottenere la risposta come XML. Per farlo, 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 in questo esempio viene utilizzato prettyprint per visualizzare i risultati barrando la risposta tramite xmllint.

L'utilità acurl non supporta l'intestazione Accept. Di conseguenza, puoi ricevi solo risposte in formato JSON con acurl.

Per utilizzare prettyprint per una risposta JSON, puoi usare 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 viene fornito un esempio della risposta:

[
  "SOAP-Message-Validation-1",
  "Spike-Arrest-1",
  "XML-to-JSON-1"
]

Per i file XML, puoi utilizzare xmllint:

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

Quando POSTI o PUTTI i 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

Ogni organizzazione che utilizza Apigee Edge per impostazione predefinita dispone di almeno due ambienti per sviluppare, testare ed eseguire il deployment delle API: "test" e "prod". Utilizza lo strumento "test" per sviluppare e testare le API prima di renderle disponibili pubblicamente. Solo i tuoi sviluppatori interni possono accedere alle API il deployment nell'ambiente di test. Esegui il deployment delle tue API in "prod" per renderle pubbliche a disposizione degli sviluppatori di app.

Debug e test

Apigee offre uno strumento di traccia che consente di eseguire il debug richiesta e risposta end-to-end dei flussi. I risultati della traccia visualizzano intestazioni e payload delle richieste e delle risposte, i valori delle variabili ed eventuali errori che si sono verificati durante il flusso.

Punti dati principali da utilizzare per la risoluzione dei problemi:

  • Timestamp: utilizza i timestamp per conoscere il tempo necessario per l'esecuzione di ogni passaggio. Il confronto dei timestamp ti aiuta a isolare i criteri la cui esecuzione richiede più tempo rallentano le chiamate API.
  • Percorso di base: verificando il percorso di base, puoi garantire che un criterio venga il routing del messaggio al server corretto.
  • Risultati dell'esecuzione del criterio: questi risultati consentono di vedere se il messaggio viene essere alterato come previsto, ad esempio se il messaggio viene trasformato da XML a JSON il messaggio viene memorizzato nella cache.

La figura seguente mostra i risultati della traccia:

Mostra la scheda Trace selezionata nell&#39;editor del proxy API nella UI di Edge.

Ogni sessione di Trace è suddivisa nei seguenti passaggi principali:

  • Richiesta originale ricevuta dal client: mostra il percorso del verbo e dell'URI della la richiesta dall'app client, dalle intestazioni, dai dati del corpo e dai parametri di query.
  • Richiesta inviata al tuo servizio di backend: mostra il messaggio di richiesta inviato a il servizio di backend dal proxy API.
  • Risposta restituita dal servizio di backend: mostra le intestazioni della risposta. e payload restituito dal servizio di backend.
  • Risposta finale inviata al client: il messaggio di risposta restituito all' che richiede l'app client dopo l'esecuzione del flusso di risposta.