Cloud Endpoints Frameworks era precedentemente noto come Endpoints. Per distinguerle, in questa pagina la nuova versione è indicata come Endpoints Frameworks versione 2.0 e la versione precedente come Endpoints versione 1.0. Questa pagina descrive come eseguire la migrazione di un'applicazione Cloud Endpoints 1.0 a Endpoints Frameworks 2.0. La migrazione consiste in una modifica della libreria e una modifica della configurazione dell'applicazione, ma non è necessario apportare modifiche al codice.
Vantaggi
La versione 2.0 di Endpoints offre una serie di vantaggi, tra cui:
- Latenza delle richieste ridotta.
- Migliore integrazione con le funzionalità di App Engine, come i domini personalizzati.
- Nuove funzionalità di gestione delle API.
La versione 2.0 di Endpoints Frameworks non influisce sulle interfacce della tua API. I client esistenti continuano a funzionare dopo la migrazione senza alcuna modifica al codice lato client.
Panoramica delle funzioni
Le seguenti funzionalità sono compatibili con le versioni precedenti di Endpoints:
- Protocollo JSON-REST, utilizzato da tutte le librerie client di Google
- Servizio di discovery
- Tutte le funzionalità di autenticazione esistenti (OAuth2/OpenID Connect)
- Supporto della libreria client per i client generati
- CORS (per gli utenti JavaScript che non utilizzano la libreria client JavaScript di Google)
- Explorer API
La suddivisione del traffico non è disponibile.
Funzionalità attualmente escluse
Le seguenti funzionalità non sono disponibili. Se hai bisogno di una di queste funzionalità, invia una richiesta di funzionalità.
- Protocollo JSON-RPC, obbligatorio per i client iOS precedenti. Per creare client iOS per l'API Endpoints Frameworks versione 2.0, ti consigliamo di utilizzare la libreria client Objective-C per le API di Google per le API REST.
- ETag automatici
- Campi
kind
automatici - Integrazione con l'ambiente IDE
fields
risposte parziali- Creazione automatica del metodo dell'API PATCH
Migrazione dalla versione 1.0 di Endpoints
Per eseguire la migrazione dalla versione 1.0:
Crea una sottocartella denominata
/lib
nella directory principale dell'applicazione.Installa la libreria dalla directory principale dell'applicazione:
pip install -t lib google-endpoints --ignore-installed
Rimuovi le voci
- name: endpoints
eversion 1.0
dal fileapp.yaml
dell'applicazione nella sezionelibraries
. Ad esempio:libraries: - name: endpoints #Remove version: 1.0 #Remove
Nella sezione
libraries
del fileapp.yaml
, aggiungi quanto segue:libraries: - name: pycrypto version: 2.6 - name: ssl version: 2.7.11
Endpoints Frameworks richiede queste versioni delle librerie
pycrypto
essl
.Nella sezione
handlers
del fileapp.yaml
, modifica la direttivaurl
da- url: /_ah/spi/.*
a- url: /_ah/api/.*
.Nella directory principale dell'applicazione, crea o modifica un file denominato
appengine_config.py
in modo da includere quanto segue:from google.appengine.ext import vendor vendor.add('lib')
Controlla la stringa della versione dell'API. La stringa di versione, specificata nel decoratore
@endpoints.api(version='v1', ...)
, viene visualizzata nel percorso dell'API. Se specifichi una stringa di versione compatibile con lo standard SemVer, nel percorso dell'API viene visualizzato solo il numero della versione principale quando esegui il deployment dell'API. Ad esempio, un'API chiamataecho
con la versione2.1.0
avrebbe un percorso come/echo/v2
. Se aggiorni l'APIecho
alla versione2.2.0
ed esegui il deployment di una modifica compatibile con le versioni precedenti, il percorso rimane/echo/v2
. In questo modo puoi aggiornare il numero di versione dell'API quando apporti una modifica compatibile con le versioni precedenti senza interrompere i percorsi esistenti per i tuoi clienti. Tuttavia, se aggiorni l'APIecho
alla versione3.0.0
(perché stai implementando una modifica che comporta una interruzione), il percorso viene modificato in/echo/v3
.Esegui di nuovo il deployment dell'applicazione Endpoints Frameworks.
Verifica di un nuovo deployment
Per verificare che il nuovo framework gestisca il traffico:
- Invia alcune richieste al nuovo deployment.
- Visita la pagina Cloud Logging per il tuo progetto.
- Se le richieste vengono mostrate con percorsi che iniziano con
/_ah/api
, significa che la tua API è ora pubblicata da Endpoints Frameworks 2.0. I log non devono mostrare richieste con percorsi che iniziano con/_ah/spi
. Queste richieste indicano che il proxy Endpoints versione 1.0 sta ancora gestendo le richieste.
Aggiunta della gestione delle API
Endpoints Frameworks versione 2.0 aggiunge funzionalità di gestione delle API, tra cui:
- Gestione delle chiavi API
- Condivisione API
- Autenticazione degli utenti
- Metriche delle API
- Log API
Per iniziare, vai alla pagina Introduzione a Endpoints Frameworks per Python.
Risoluzione dei problemi
Questa sezione descrive i comportamenti erratici comuni durante la migrazione alla versione 2.0 di Endpoints Frameworks e le soluzioni suggerite.
L'API restituisce errori 404
, ma Explorer API le elenca comunque correttamente
Devi rimuovere la vecchia configurazione di Endpoints 1.0 quando esegui la migrazione alla versione 2.0 di Endpoints Frameworks. Se la vecchia configurazione è ancora presente nella configurazione dell'applicazione, il servizio Endpoints continua a trattare l'app come un'app della versione 1.0. Nei log di App Engine potresti visualizzare richieste inviate a /_ah/spi
, che generano errori HTTP 404
inviati al client.
Se presenti, rimuovi le seguenti righe dal file
app.yaml
:handlers: - url: /_ah/spi/.* script: ...
Assicurati che la sezione
handlers
nel fileapp.yaml
abbia il percorso corretto:handlers: # The endpoints handler must be mapped to /_ah/api. - url: /_ah/api/.* script: ...
Messaggio di errore: ImportError: cannot import name locked_file
Questo accade se le dipendenze contengono una versione della libreria oauth2client
non compatibile con App Engine. Consulta il
problema noto.