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 buone soluzioni per l'hosting delle destinazioni webhook. Cloud Run offre maggiore flessibilità ed è in grado di gestire volumi più grandi con la concorrenza.

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

  • 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)

Crea una destinazione webhook in Cloud Run

Utilizzando Cloud Run, puoi definire una destinazione 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 indice dell'URL è configurata per accettare solo richieste POST e prevede che i dati vengano forniti tramite un payload JSON.

Integrare il provider di webhook

La maggior parte dei servizi che forniscono callback HTTP richiede la verifica della proprietà dell'URL. In genere, questa operazione viene eseguita inviando una sorta di token, messaggio o segreto e aspettandosi una risposta valida. Dovrai ottenere questi requisiti dal fornitore di servizi. Utilizzando il target webhook dell'esempio precedente, il risultato potrebbe essere il seguente:

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

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

Autorizzazione delle richieste

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

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

Quando memorizzi 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 destinazione del webhook potrà inviare messaggi. In questo caso, l'implementazione del webhook deve essere sicura da esporre a internet pubblico.

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 dei tentativi integrati se si verifica una risposta di errore, ad esempio un codice di stato HTTP 4xx o 5xx, quindi devi 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. Il periodo più breve tra i due verrà applicato alla tua richiesta. Se l'elaborazione dei dati supera il tempo assegnato da Cloud Run o dal fornitore di webhook, devi 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 esito positivo al provider di webhook e continuare l'elaborazione senza il problema del timeout. Sono anche buone opzioni per la gestione di errori e tentativi.

Pattern comuni di webhook

Tipo Esempi
Ritrasmissione 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 Eseguire azioni su Dialogflow, pubblicare risposte su Twitter o eseguire il push nell'ambiente di staging ogni volta che viene eseguito il commit di un nuovo codice in GitHub.

Passaggi successivi