Hosting di destinazioni di webhook

Questa guida mostra come configurare l'hosting di una destinazione di webhook in un servizio Cloud Run.

Cloud Run offre ottime soluzioni per l'hosting delle destinazioni di webhook. Cloud Run offre maggiore flessibilità ed è in grado di gestire volumi più elevati con la concorrenza.

L'hosting delle destinazioni di webhook in un servizio Cloud Run è ideale per i seguenti scenari:

  • Vuoi timeout delle richieste più lunghi (fino a 60 minuti).
  • Prevedi un volume elevato e hai bisogno di concorrenza (fino a 1000 richieste in parallelo per istanza).

Creare una destinazione di webhook in Cloud Run

Con Cloud Run, puoi definire una destinazione di webhook in qualsiasi lingua tu scelga. Devi solo creare un endpoint HTTP in grado di accettare i dati. In genere, questa operazione viene eseguita con un POST, ad esempio:

from flask import Flask, request
app = Flask(__name__)

@app.route('/', methods=['POST'])
def index():
    data = request.get_json()
    return ('', 200)

In questo esempio, la pagina di indice dell'URL è configurata per accettare solo le richieste POST e prevede che i dati vengano forniti tramite un payload JSON.

Eseguire l'integrazione con il provider di webhook

La maggior parte dei servizi che forniscono callback HTTP richiede di verificare la proprietà dell'URL. In genere, questa operazione viene eseguita inviando una sorta di token, messaggio o secret e prevedendo una risposta valida. Dovrai ottenere questi requisiti dal fornitore di servizi. Utilizzando la destinazione di webhook di esempio precedente, potrebbe essere simile a questa:

@app.route('/', methods=['POST'])
def index():
    data = request.get_json()
    return data['challenge']

Dopo che il provider ha verificato la tua proprietà, dovrai aggiungere anche l'autorizzazione.

Autorizzazione delle richieste

Una destinazione di webhook è un URL aperto e pubblico. La maggior parte dei servizi fornisce un token o un secret per garantire che le richieste in entrata provengano da servizi autorizzati. Poiché l'URL è pubblico, non puoi impedire tentativi dannosi di inviare dati alla destinazione di webhook. Tuttavia, l'utilizzo di token o secret garantisce l'elaborazione dei dati solo da origini autorizzate.

Per verificare la richiesta, puoi configurare i secreto archiviare la tua copia del secret come variabile di ambiente o utilizzando una sorta di sistema di gestione delle chiavi.

Quando archivi la tua copia del secret come variabile di ambiente, ogni richiesta deve avere un secret o un token nelle intestazioni della richiesta o nel payload JSON e devi controllarlo per assicurarti che l'origine sia valida.

import os
from flask import request

@app.route('/', methods=['POST'])
def index():
    request_secret = request.headers.get('Secret')
    if request_secret != os.environ.get('SECRET'):
        return ('Unauthorized', 401)
    return ('', 200)

Se il provider di webhook non supporta un secret o un altro meccanismo di autenticazione, chiunque abbia l'URL della tua destinazione di webhook potrà inviare messaggi. In questo caso, l'implementazione del webhook deve essere sicura per l'esposizione 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 in caso di risposta di errore, ad esempio un codice di stato HTTP 4xx o 5xx, quindi dovrai restituire un codice di stato riuscito (2xx) per comunicare al servizio che l'evento è stato elaborato correttamente.

@app.route('/', methods=['POST'])
def index():
    data = request.get_json()
    return ('', 200)

Timeout

Sia Cloud Run sia il provider di webhook hanno timeout. Alla tua applicazione verrà applicato il più breve dei due. 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 provider di webhook e continuare l'elaborazione senza preoccuparti del timeout. Queste sono anche buone opzioni per gestire errori e tentativi.

Pattern di webhook comuni

Tipo Esempi
Trasmissione dei dati Invio di una notifica utilizzando Firebase Cloud Messaging ogni volta che viene chiamato il webhook.
Archiviazione dei dati Archiviazione dei dati in BigQuery per analisi successive.
Attivazione di azioni 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