Questa guida mostra come ospitare una destinazione di webhook in un servizio Cloud Run.
Funzioni Cloud Run e Cloud Run
Sia le funzioni Cloud Run sia Cloud Run offrono ottime soluzioni per ospitare i tuoi target webhook. In genere, le funzioni di Cloud Run sono rapide da configurare, ideale per la prototipazione e ideale per flussi di lavoro a basso volume. Cloud Run offre maggiore flessibilità ed è in grado di gestire volumi più grandi in contemporanea.
Utilizza Cloud Run se:
- Utilizzi linguaggi o runtime non supportati nelle funzioni Cloud Run
- Vuoi timeout delle richieste più lunghi (fino a 15 minuti)
- Prevedi un volume elevato e hai bisogno di contemporaneità (80 richieste in parallelo per istanza)
Creazione di una destinazione webhook in Cloud Run
Con Cloud Run, puoi definire una destinazione di webhook in qualsiasi lingua. Devi solo creare un endpoint HTTP in grado di accettare i dati.
In genere questa operazione viene eseguita con un POST
, ad esempio:
@app.route('/', methods=['POST'])
def index():
data = request.get_json()
Nell'esempio precedente, la pagina di indice dell'URL è configurata per accettare solo
POST
richiede e si aspetta che i dati vengano consegnati tramite un payload JSON.
Integrazione con il provider webhook
La maggior parte dei servizi che forniscono callback HTTP richiede la verifica della proprietà dell'URL. Di solito, questo viene fatto inviando un qualche tipo di token, messaggio o segreto. in attesa di una risposta valida. Dovrai ottenere questi requisiti dal fornitore di servizi. Utilizzando lo stesso esempio precedente, il risultato potrebbe essere il seguente:
def index():
data = request.get_json()
return data['challenge']
Dopo che il provider ha verificato la tua proprietà, dovrai aggiungere l'autorizzazione anche la tua parte.
Autorizzazione delle richieste
Un target webhook è un URL aperto e pubblico. La maggior parte dei servizi fornisce un token o un segreto per garantire che le richieste in arrivo provengano da servizi autorizzati. Poiché l'URL è pubblico, non è possibile impedire tentativi dannosi di inviare dati a della destinazione del webhook. Tuttavia, l'utilizzo di token o segreti ti garantisce di elaborare solo i dati provenienti da fonti autorizzate.
Per verificare la richiesta, puoi: configure secret (configura i secret) o memorizza una tua copia del secret come variabile di ambiente o utilizzando un sistema di gestione delle chiavi.
Quando memorizzi la copia del secret come variabile di ambiente, ogni richiesta deve avere un secret o un token negli header della richiesta o nel payload JSON e devi controllarlo per assicurarti che l'origine sia valida.
def index():
request_secret = request.headers['Secret']
if request_secret != os.environ['SECRET']:
return ('Unauthorized', 401)
Se il provider webhook non supporta un secret o un'altra autenticazione meccanismo di attenzione, chiunque abbia l'URL del target del webhook potrà inviare messaggi. In questo caso, l'implementazione dell'webhook dovrebbe essere sicura da esporre alla rete internet pubblica.
Rispondere alle richieste
La maggior parte dei servizi richiede di rispondere a una richiesta entro un determinato periodo di tempo, come specificato dal servizio. Alcuni webhook hanno metodi di ripetizione integrati se viene generata una risposta di errore, ad esempio un codice di stato HTTP 4xx o 5xx, pertanto dovrai restituire un codice di stato di esito positivo (2xx) per comunicare al servizio che l'evento è stato elaborato correttamente.
def index():
data = request.get_json()
return ('', 200)
Timeout
Sia Cloud Run sia il provider di webhook hanno dei timeout. L'opzione più breve dei due sarà valida per la tua applicazione. Se l'elaborazione dei dati supera il tempo assegnato da Cloud Run o dal provider di webhook, dovrai utilizzare un prodotto che ti consenta di completare l'elaborazione in modo asincrono, ad esempio Pub/Sub o Cloud Tasks. Questi prodotti ti consentono di trasferire rapidamente i dati, restituire immediatamente una risposta di successo al fornitore di webhook e continuare l'elaborazione senza problemi di timeout. Sono anche ottime opzioni per la gestione di errori e nuovi tentativi.
Pattern comuni dei webhook
Tipo | Esempi |
---|---|
Inoltro dei dati | Invio di una notifica tramite Firebase Cloud Messaging ogni volta che viene chiamato il webhook. |
Archiviazione dei dati | Archiviazione dei dati in BigQuery per analisi successive. |
Azioni di attivazione | Esecuzione di azioni su Dialogflow, pubblicazione di risposte su Twitter o push nell'ambiente di staging ogni volta che viene eseguito il commit di nuovo codice in GitHub. |
Passaggi successivi
- Scopri di più sui webhook (trigger HTTP) nelle funzioni Cloud Run
- Configurare le notifiche webhook in Google Cloud Observability
- Inviare messaggi Pub/Sub a un webhook utilizzando le sottoscrizioni push
- Eseguire le azioni su Dialogflow con i webhook