Cloud Endpoints accetta un insieme di estensioni specifiche di Google per la specifica OpenAPI che configurano i comportamenti di Extensible Service Proxy (ESP) e Service Control. In questa pagina vengono descritte le estensioni specifiche di Google alla specifica OpenAPI.
Sebbene gli esempi riportati di seguito siano in formato YAML, è supportato anche JSON.
Convenzione di denominazione
Le estensioni Google OpenAPI hanno nomi che iniziano con il prefisso x-google-
.
x-google-allow
x-google-allow: [configured | all]
Questa estensione viene utilizzata al livello superiore di una specifica OpenAPI per indicare quali percorsi URL devono essere consentiti tramite ESP.
I valori possibili sono configured
e all
.
Il valore predefinito è configured
, il che significa che solo i metodi API elencati nella specifica OpenAPI vengono pubblicati tramite ESP.
Quando viene utilizzato all
, le chiamate non configurate, con o senza una chiave API o l'autenticazione utente, passano attraverso ESP alla tua API.
ESP elabora le chiamate alla tua API in modo sensibile alle maiuscole.
Ad esempio, ESP considera /widgets
e /Widgets
come
metodi API diversi.
Quando utilizzi all
, devi prestare particolare attenzione in due aree:
- Qualsiasi chiave API o regola di autenticazione.
- Il routing del percorso di backend nel servizio.
Come best practice, ti consigliamo di configurare l'API in modo da utilizzare il routing dei percorsi sensibile alle maiuscole. Utilizzando il routing sensibile alle maiuscole, la tua API restituisce un codice di stato HTTP 404
quando il metodo richiesto nell'URL non corrisponde al nome del metodo API elencato nella specifica OpenAPI. Tieni presente che i framework di applicazioni web come Node.js Express dispongono di un'impostazione per attivare o disattivare il routing sensibile alle maiuscole. Il comportamento predefinito dipende dal
framework utilizzato. Ti consigliamo di esaminare le impostazioni del framework per assicurarti che il routing sensibile alle maiuscole sia abilitato. Questo suggerimento concorda con la specifica OpenAPI v2.0 che afferma: "Tutti i nomi dei campi nella specifica sono sensibili alle maiuscole".
Esempio
Supponiamo che:
x-google-allow
è impostato suall
.- Il metodo API
widgets
è elencato nella specifica OpenAPI, ma nonWidgets
. - Hai configurato la tua specifica OpenAPI in modo che richieda una chiave API.
Poiché widgets
è elencato nella tua specifica OpenAPI, ESP blocca la seguente richiesta perché non ha una chiave API:
https://my-project-id.appspot.com/widgets
Poiché Widgets
non è elencato nella tua specifica OpenAPI, ESP passa la seguente richiesta al tuo servizio senza una chiave API:
https://my-project-id.appspot.com/Widgets/
Se la tua API utilizza il routing sensibile alle maiuscole (e non hai instradato chiamate a "Widgets " a nessun codice), il backend dell'API restituisce un 404
. Tuttavia, se utilizzi il routing senza distinzione tra maiuscole e minuscole, il backend dell'API instrada questa chiamata a "widget".
Linguaggi e framework diversi hanno metodi diversi per controllare la sensibilità alle maiuscole e il routing. Consulta la documentazione del tuo framework per i dettagli.
x-google-backend
L'estensione x-google-backend
specifica come instradare le richieste
a backend locali o remoti. L'estensione può essere specificata al livello
superiore e/o operativo di una specifica OpenAPI.
Per impostazione predefinita, ESP è configurato in modo da indirizzare tutto il traffico a un singolo backend locale. L'indirizzo di backend locale è specificato dal flag --backend
(il valore predefinito è http://127.0.0.1:8081
). Puoi utilizzare l'estensione x-google-backend
per sostituire questo comportamento predefinito e specificare uno o più backend o remoti locali che possono ricevere richieste.
L'estensione x-google-backend
può anche configurare altre impostazioni per i backend locali e remoti, come l'autenticazione e i timeout. Tutte queste configurazioni possono essere applicate per singola operazione.
L'estensione x-google-backend
contiene i seguenti campi:
address
address: URL
Facoltativo. L'URL del backend di destinazione.
Lo schema dell'indirizzo deve essere http
o https
.
Durante il routing a backend remoti (serverless), l'indirizzo deve essere impostato e la parte dello schema deve essere https
.
Se un'operazione utilizza x-google-backend
ma non specifica address
,
ESPv2 instrada le richieste al backend locale specificato dal flag --backend
.
jwt_audience | disable_auth
Deve essere impostata solo una di queste due proprietà.
Se un'operazione utilizza x-google-backend
ma non specifica jwt_audience
o disable_auth
, ESPv2 utilizzerà automaticamente jwt_audience
in modo che corrisponda a address
.
Se il criterio address
non viene configurato, ESPv2 imposterà automaticamente disable_auth
su true
.
jwt_audience
jwt_audience: string
Facoltativo. Il pubblico JWT specificato quando ESPv2 ottene un token ID istanza, che viene quindi utilizzato quando si effettua la richiesta di backend di destinazione.
Quando configuri Endpoints per Serverless, il backend remoto deve essere protetto per consentire solo il traffico da ESPv2. ESPv2 collegherà un token ID istanza all'intestazione Authorization
durante l'esecuzione delle richieste proxy.
Il token ID istanza rappresenta l'account di servizio di runtime utilizzato per eseguire il deployment di ESPv2. Il backend remoto può quindi verificare che la richiesta provenga da
ESPv2 in base a questo token collegato.
Ad esempio, un backend remoto di cui è stato eseguito il deployment su Cloud Run può utilizzare IAM per:
- Limita le chiamate non autenticate revocando
roles/run.invoker
dall'entitàallUsers
speciale. - Consenti solo a ESPv2 di richiamare il backend concedendo il ruolo
roles/run.invoker
all'account di servizio di runtime ESPv2.
Per impostazione predefinita, ESPv2 crea il token ID istanza con un segmento di pubblico JWT che corrisponde al campo address
. La specifica manuale di jwt_audience
è necessaria solo quando il backend di destinazione utilizza l'autenticazione basata su JWT e il pubblico previsto è diverso dal valore specificato nel campo address
.
Per i backend remoti di cui è stato eseguito il deployment in App Engine o con IAP, devi eseguire l'override del pubblico JWT. App Engine e IAP utilizzano il proprio ID client OAuth come pubblico previsto.
Quando questa funzionalità è abilitata, ESPv2 modificherà le intestazioni nelle richieste.
Se per una richiesta è già impostata l'intestazione Authorization
, ESPv2:
- Copia il valore originale in una nuova intestazione
X-Forwarded-Authorization
. - Esegui l'override dell'intestazione
Authorization
con il token ID istanza.
Di conseguenza, se un client API imposta l'intestazione Authorization
, un backend in esecuzione
dietro ESPv2 deve utilizzare l'intestazione X-Forwarded-Authorization
per
recuperare l'intero JWT. Il backend deve verificare il JWT in questa intestazione, poiché ESPv2 non eseguirà la verifica quando i metodi di autenticazione non sono configurati.
disable_auth
disable_auth: bool
Facoltativo. Questa proprietà determina se ESPv2 deve impedire l'ottenimento di un token ID di istanza e il relativo collegamento alla richiesta.
Quando configuri il backend di destinazione, è possibile che tu non voglia utilizzare IAP o IAM per autenticare le richieste da ESPv2 se si applica una delle seguenti condizioni:
- Il backend dovrebbe consentire chiamate non autenticate.
- Il backend richiede l'intestazione
Authorization
originale dal client API e non può utilizzareX-Forwarded-Authorization
(descritto nella sezionejwt_audience
).
In questo caso, imposta questo campo su true
.
path_translation
path_translation: [ APPEND_PATH_TO_ADDRESS | CONSTANT_ADDRESS ]
Facoltativo. Imposta la strategia di traduzione del percorso utilizzata da ESPv2 durante il proxy delle richieste al backend di destinazione.
Per ulteriori dettagli sulla traduzione del percorso, consulta la sezione Informazioni sulla traduzione del percorso.
Quando x-google-backend
viene utilizzato al livello superiore della specifica OpenAPI, il valore predefinito di path_translation
è APPEND_PATH_TO_ADDRESS
, mentre quando x-google-backend
viene utilizzato al livello di operazione della specifica OpenAPI, il valore predefinito di path_translation
è CONSTANT_ADDRESS
. Se il campo address
non è presente, il valore path_translation
rimarrà non specificato e non verrà visualizzato.
deadline
deadline: double
Facoltativo. Il numero di secondi di attesa per una risposta completa da una richiesta.
Le risposte che richiedono più tempo rispetto alla scadenza configurata scadranno.
La scadenza predefinita è di 15.0
secondi.
I valori non positivi non verranno rispettati. In questi casi, ESPv2 utilizzerà automaticamente il valore predefinito.
La scadenza non può essere disattivata, ma può essere impostata su un numero elevato, ad esempio 3600.0
per un'ora.
protocol
protocol: [ http/1.1 | h2 ]
Facoltativo. Il protocollo utilizzato per inviare una richiesta al backend.
I valori supportati sono http/1.1
e h2
.
Il valore predefinito è http/1.1
per i backend HTTP e HTTPS.
Per i backend HTTP sicuri (https://) che supportano HTTP/2,
imposta questo campo su h2
per migliorare le prestazioni. Questa è l'opzione consigliata per i backend serverless di Google Cloud.
Abilitazione del supporto dei backend in ESP
ESPv2 rileverà automaticamente quando x-google-backend
è configurato.
Per abilitare questa funzionalità, l'ESP richiede una modifica manuale della configurazione.
Abilita il supporto x-google-backend
in ESP fornendo l'argomento --enable_backend_routing
quando esegui il container ESP.
(Per i runtime in cui non controlli le opzioni dei container ESP, questa opzione è già fornita). Di seguito è riportato un esempio di abilitazione del supporto x-google-backend
durante il deployment del container ESP in GKE (questo esempio si basa sull'esempio del tutorial sugli endpoint su GKE):
- name: esp image: gcr.io/endpoints-release/endpoints-runtime:1 args: [ "--http_port", "8081", "--service", "SERVICE_NAME", "--rollout_strategy", "managed", "--enable_backend_routing" ]
Informazioni sulla traduzione dei percorsi
Poiché l'ESP gestisce le richieste, prenderà il percorso della richiesta originale e lo tradurrà prima di inviare una richiesta al backend di destinazione. Il modo esatto in cui avviene questa traduzione dipende dalla strategia di traduzione del percorso in uso. Esistono due strategie di traduzione dei percorsi:
APPEND_PATH_TO_ADDRESS
: il percorso della richiesta del backend di destinazione viene calcolato aggiungendo il percorso della richiesta originale all'URLaddress
dell'estensionex-google-backend
.CONSTANT_ADDRESS
: il percorso di richiesta target è costante, come definito dall'URLaddress
dell'estensionex-google-backend
. Se il percorso OpenAPI corrispondente contiene parametri, il nome del parametro e il relativo valore diventano parametri di ricerca.
Esempi:
APPEND_PATH_TO_ADDRESS
address: https://my-project-id.appspot.com/BASE_PATH
- Con i parametri del percorso OpenAPI
- Percorso OpenAPI:
/hello/{name}
- Percorso richiesta:
/hello/world
- URL richiesta target:
https://my-project-id.appspot.com/BASE_PATH/hello/world
- Percorso OpenAPI:
- Senza parametri del percorso OpenAPI
- Percorso OpenAPI:
/hello
- Percorso richiesta:
/hello
- URL richiesta target:
https://my-project-id.appspot.com/BASE_PATH/hello
- Percorso OpenAPI:
CONSTANT_ADDRESS
address
:https://us-central1-my-project-id.cloudfunctions.net/helloGET
- Con i parametri del percorso OpenAPI
- Percorso OpenAPI:
/hello/{name}
- Percorso richiesta:
/hello/world
- URL richiesta target:
https://us-central1-my-project-id.cloudfunctions.net/helloGET?name=world
- Percorso OpenAPI:
- Senza parametri del percorso OpenAPI
- Percorso OpenAPI:
/hello
- Percorso richiesta:
/hello
- URL richiesta target:
https://us-central1-my-project-id.cloudfunctions.net/helloGET
- Percorso OpenAPI:
x-google-endpoints
Questa sezione descrive gli utilizzi dell'estensione x-google-endpoints
.
Configurazione del DNS nel dominio cloud.goog
in corso...
Se hai eseguito il deployment dell'applicazione su Compute Engine o Google Kubernetes Engine, puoi creare una voce DNS per il servizio Endpoints sul dominio cloud.goog
aggiungendo quanto segue al documento OpenAPI:
x-google-endpoints: - name: "API_NAME.endpoints.PROJECT_ID.cloud.goog" target: "IP_ADDRESS"
Aggiungi l'estensione x-google-endpoints
al livello superiore del documento OpenAPI (non rientrato o nidificato). Devi configurare il nome di dominio nel formato:
.endpoints.PROJECT_ID.cloud.goog
Ad esempio:
swagger: "2.0" host: "my-cool-api.endpoints.my-project-id.cloud.goog" x-google-endpoints: - name: "my-cool-api.endpoints.my-project-id.cloud.goog" target: "192.0.2.1"
Il dominio .cloud.goog
è gestito da Google e condiviso dai clienti di Google Cloud. Poiché gli ID progetto Google Cloud sono univoci a livello globale, un nome di dominio nel formato .endpoints.PROJECT_ID.cloud.goog
è un nome di dominio univoco per la tua API.
Per semplicità, configura i campi host
e x-google-endpoints.name
in modo che siano uguali. Quando esegui il deployment del documento OpenAPI, Service Management crea:
- Un servizio gestito con il nome che hai specificato nel campo
host
. - Un record A DNS che utilizza il nome e l'indirizzo IP che hai configurato nell'estensione
x-google-endpoints
.
Per le API ospitate nell'ambiente flessibile di App Engine, puoi utilizzare il dominio appspot.com
. Per ulteriori informazioni, consulta Configurazione degli endpoint.
Configurazione di ESP per consentire le richieste CORS
Se l'API viene chiamata da un'applicazione web su un'origine diversa, deve supportare la condivisione delle risorse tra origini (CORS). Consulta l'articolo sull'aggiunta del supporto CORS a ESP per informazioni sulla configurazione di ESP per il supporto di CORS.
Se devi implementare il supporto CORS personalizzato nel codice di backend, imposta allowCors: True
in modo che ESP passi tutte le richieste CORS al codice di backend:
x-google-endpoints: - name: "API_NAME.endpoints.PROJECT_ID.cloud.goog" allowCors: True
Aggiungi l'estensione x-google-endpoints
al livello principale del documento OpenAPI (non rientrato o nidificato), ad esempio:
swagger: "2.0" host: "my-cool-api.endpoints.my-project-id.cloud.goog" x-google-endpoints: - name: "my-cool-api.endpoints.my-project-id.cloud.goog" allowCors: True
x-google-issuer
x-google-issuer: URI | EMAIL_ADDRESS
Questa estensione viene utilizzata nella sezione OpenAPI securityDefinitions
per specificare l'emittente di una credenziale. I valori possono assumere la forma di un nome host o di un indirizzo email.
x-google-jwks_uri
x-google-jwks_uri: URI
URI della chiave pubblica del provider impostata per convalidare la firma del token web JSON.
ESP supporta due formati di chiave pubblica asimmetrica definiti dall'estensione OpenAPI x-google-jwks_uri
:
-
Formato JWK impostato.
Ad esempio:
x-google-jwks_uri: "https://YOUR_ACCOUNT_NAME.YOUR_AUTH_PROVIDER_URL/.well-known/jwks.json"
-
X509. Ad esempio:
x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com"
Se utilizzi un formato di chiave simmetrica, imposta x-google-jwks_uri
sull'URI di un file contenente la stringa di chiave con codifica base64url.
Se ometti x-google-jwks_uri
, ESP seguirà il protocollo OpenID Connect Discovery per rilevare automaticamente l'URI JWKS per il provider OpenID specificato.
ESP effettuerà una richiesta a x-google-issuer/.well-known/openid-configuration
, analizzerà la risposta JSON e leggerà l'URI JWKS dal campo jwks_uri
di primo livello.
Tieni presente che l'omissione di x-google-jwks_uri
comporterà tempi di avvio a freddo più elevati, poiché l'ESP deve effettuare una chiamata remota aggiuntiva all'avvio.
Di conseguenza, è consigliabile omettere questo campo solo se l'URI JWKS cambia spesso.
La maggior parte dei provider OpenID certificati (come Google, Auth0 e Okta) hanno URI JWKS stabili.
x-google-jwt-locations
Per impostazione predefinita, un JWT viene passato nell'intestazione Authorization
(preceduta da "Bearer "
), nell'intestazione X-Goog-Iap-Jwt-Assertion
o nel parametro di query access_token
. Consulta Esecuzione di una chiamata autenticata a un'API Endpoints per esempi su come passare un JWT.
In alternativa, utilizza l'estensione x-google-jwt-locations
nella sezione securityDefinitions di OpenAPI per fornire le posizioni personalizzate da cui estrarre il token JWT.
L'estensione x-google-jwt-locations
accetta un elenco di località JWT. Ogni posizione JWT contiene i seguenti campi:
Elemento | Description |
---|---|
header/query |
Obbligatorio. Il nome dell'intestazione contenente il JWT o il nome del parametro di query contenente il JWT. |
value_prefix |
Facoltativo. Solo per l'intestazione. Quando viene impostato value_prefix , il suo valore deve corrispondere al prefisso del valore dell'intestazione contenente il JWT.
|
Ad esempio:
x-google-jwt-locations:
# Expect header "Authorization": "MyBearerToken <TOKEN>"
- header: "Authorization"
value_prefix: "MyBearerToken "
# expect header "jwt-header-foo": "jwt-prefix-foo<TOKEN>"
- header: "jwt-header-foo"
value_prefix: "jwt-prefix-foo"
# expect header "jwt-header-bar": "<TOKEN>"
- header: "jwt-header-bar"
# expect query parameter "jwt_query_bar=<TOKEN>"
- query: "jwt_query_bar"
Se vuoi supportare solo un sottoinsieme di località JWT predefinite, elencale esplicitamente nell'estensione x-google-jwt-locations
. Ad esempio, per includere il supporto solo per l'intestazione Authorization
con il prefisso "Bearer "
:
x-google-jwt-locations:
# Support the default header "Authorization": "Bearer <TOKEN>"
- header: "Authorization"
value_prefix: "Bearer "
x-google-audiences
x-google-audiences: STRING
Questa estensione viene utilizzata nella sezione OpenAPI securityDefinitions
per fornire un elenco di segmenti di pubblico a cui il campo JWT aud
deve corrispondere durante l'autenticazione JWT.
Questa estensione accetta una singola stringa con valori separati da una virgola. Non sono consentiti
spazi tra i segmenti di pubblico. Se non è specificato, il campo JWT aud
deve corrispondere al campo host
nel documento OpenAPI, a meno che non venga utilizzato il flag --disable_jwt_audience_service_name_check
. Se viene utilizzato il flag e x-google-audiences
non è specificato, il campo JWT aud
non viene selezionato.
securityDefinitions: google_id_token: type: oauth2 authorizationUrl: "" flow: implicit x-google-issuer: "https://accounts.google.com" x-google-jwks_uri: "https://www.googleapis.com/oauth2/v1/certs" x-google-audiences: "848149964201.apps.googleusercontent.com,841077041629.apps.googleusercontent.com"
x-google-management
L'estensione x-google-management
controlla diversi aspetti della gestione delle API e contiene i campi descritti in questa sezione.
metrics
Puoi utilizzare metrics
insieme a quota e x-google-quota
per configurare una quota per la tua API. Una quota consente di controllare la frequenza con cui le applicazioni possono chiamare i metodi nell'API. Ad esempio:
x-google-management:
metrics:
- name: read-requests
displayName: Read requests
valueType: INT64
metricKind: DELTA
Il campo metrics
contiene un elenco con le seguenti coppie chiave-valore:
Elemento | Description |
---|---|
name | Obbligatorio. Il nome di questa metrica. In genere, questo è il tipo di richiesta (ad esempio, "read-requests" o "write-requests") che identifica in modo univoco la metrica. |
displayName | Facoltativo, ma consigliato. Il testo visualizzato per identificare la metrica nella scheda Quote della pagina Endpoint > Servizi nella console Google Cloud. Questo testo viene mostrato anche ai consumatori della tua API nelle pagine Quote in IAM e amministrazione e API e servizi. Il nome visualizzato deve contenere un massimo di 40 caratteri. Per motivi di leggibilità, l'unità del limite di quota associato viene aggiunta automaticamente al nome visualizzato nella console Google Cloud. Ad esempio, se specifichi "Richieste di lettura" come nome visualizzato, nella console Google Cloud verrà visualizzato il messaggio "Richieste di lettura al minuto per progetto". Se non specificata, ai consumatori della tua API viene mostrata la dicitura "quota senza etichetta" nelle pagine Quote in IAM e amministrazione e API e servizi. Per mantenere la coerenza con i nomi visualizzati dei servizi Google elencati nella pagina Quote visualizzata dai consumatori della tua API, consigliamo quanto segue per il nome visualizzato:
|
valueType | Obbligatorio. Deve essere INT64 |
metricKind | Obbligatorio. Deve essere DELTA |
quota
Puoi specificare il limite quota per una metrica definita nella sezione quota
. Ad esempio:
quota:
limits:
- name: read-requests-limit
metric: read-requests
unit: 1/min/{project}
values:
STANDARD: 5000
Il campo quota.limits
contiene un elenco con le seguenti coppie chiave-valore:
Elemento | Description |
---|---|
name | Obbligatorio. Nome del limite, che deve essere univoco all'interno del servizio. Può contenere lettere minuscole e maiuscole, numeri e "-" (il carattere del trattino) e una lunghezza massima di 64 caratteri. |
metrica | Obbligatorio. Il nome della metrica a cui si applica questo limite. Questo nome deve corrispondere al testo specificato nel nome di una metrica. Se il testo specificato non corrisponde al nome di una metrica, viene visualizzato un errore quando esegui il deployment del documento OpenAPI. |
unità | Obbligatorio. L'unità del limite. Attualmente è supportato solo "1/min/{progetto}", il che significa che il limite viene applicato in base al progetto e l'utilizzo viene reimpostato ogni minuto. |
valori | Obbligatorio. Il limite per la metrica. Devi specificare questo valore come coppia chiave-valore nel seguente formato: STANDARD: YOUR-LIMIT-FOR-THE-METRICSostituisci YOUR-LIMIT-FOR-THE-METRIC con un valore intero
che corrisponde al numero massimo di richieste consentite per l'unità specificata
(attualmente solo al minuto, per progetto). Ad esempio:values: STANDARD: 5000 |
x-google-quota
L'estensione x-google-quota
viene utilizzata nella sezione paths
OpenAPI per associare un metodo nell'API a una metrica. Ai metodi senza definizione di x-google-quota
non sono applicati limiti di quota. Ad esempio:
x-google-quota:
metricCosts:
read-requests: 1
L'estensione x-google-quota
contiene il seguente elemento:
Elemento | Description |
---|---|
metricCosts | Una coppia chiave-valore definita dall'utente: "YOUR-METRIC-NAME": METRIC-COST .
|
Esempi di quote
L'esempio seguente mostra l'aggiunta di una metrica e un limite per le richieste di lettura e di scrittura.
x-google-management:
metrics:
# Define a metric for read requests.
- name: "read-requests"
displayName: "Read requests"
valueType: INT64
metricKind: DELTA
# Define a metric for write requests.
- name: "write-requests"
displayName: "Write requests"
valueType: INT64
metricKind: DELTA
quota:
limits:
# Rate limit for read requests.
- name: "read-requests-limit"
metric: "read-requests"
unit: "1/min/{project}"
values:
STANDARD: 5000
# Rate limit for write requests.
- name: "write-request-limit"
metric: "write-requests"
unit: "1/min/{project}"
values:
STANDARD: 5000
paths:
"/echo":
post:
description: "Echo back a given message."
operationId: "echo"
produces:
- "application/json"
responses:
200:
description: "Echo"
schema:
$ref: "#/definitions/echoMessage"
parameters:
- description: "Message to echo"
in: body
name: message
required: true
schema:
$ref: "#/definitions/echoMessage"
x-google-quota:
metricCosts:
read-requests: 1
security:
- api_key: []
x-google-api-name
Se il servizio contiene una sola API, il nome dell'API corrisponde a quello del servizio endpoint. Gli endpoint utilizzano il nome
specificato nel campo host
del documento OpenAPI come nome del
servizio. Se il servizio contiene più di un'API, puoi specificare i nomi delle API aggiungendo l'estensione x-google-api-name
al documento OpenAPI. L'estensione x-google-api-name
ti consente di assegnare nomi espliciti alle singole API e di stabilire un controllo delle versioni indipendente per ogni API.
Ad esempio, puoi configurare un servizio denominato api.example.com
con due API,
producer e consumer, con i frammenti di documento OpenAPI riportati di seguito:
API Producer in
producer.yaml
:swagger: 2.0 host: api.example.com x-google-api-name: producer info: version: 1.0.3
API Consumer in
consumer.yaml
:swagger: 2.0 host: api.example.com x-google-api-name: consumer info: version: 1.1.0
Puoi eseguire il deployment dei due documenti OpenAPI congiuntamente con:
gcloud endpoints services deploy producer.yaml consumer.yaml