Alojar un destino de webhook

En esta guía, se muestra cómo alojar el destino de un webhook en un servicio de Knative serving.

Cloud Functions frente a Knative serving

Cloud Functions y Knative serving proporcionan buenas soluciones para alojar tus destinos de webhook. En general, Cloud Functions se configura con rapidez, es bueno para el prototipado y es ideal para flujos de trabajo de menor volumen. Knative serving proporciona más flexibilidad y puede manejar volúmenes más grandes con simultaneidad.

Usa Knative serving en los siguientes casos:

  • Usas lenguajes o entornos de ejecución no compatibles con Cloud Functions.
  • Deseas tiempos de espera de solicitudes más largos (hasta 15 minutos).
  • Esperas un gran volumen y necesitas simultaneidad (80 solicitudes simultáneas o más por instancia de contenedor)

Crea un destino de webhook en Knative serving

Con Knative serving, puedes definir un destino de webhook en el lenguaje que elijas. Solo necesitas crear un extremo HTTP que pueda aceptar los datos. Por lo general, esto se hace con una solicitud POST, como en el siguiente ejemplo:

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

En el ejemplo anterior, la página de índice de la URL se configuró para aceptar solo solicitudes POST y espera que los datos se entreguen mediante una carga útil de JSON.

Integra al proveedor de webhook

La mayoría de los servicios que proporcionan devoluciones de llamadas HTTP requieren que verifiques la propiedad de la URL. Por lo general, se hace mediante el envío de algún tipo de token, mensaje o secreto y la espera de una respuesta válida. Deberás obtener estos requisitos del proveedor de servicios. Mediante el mismo ejemplo anterior, podría verse de la siguiente forma:

def index():
    data = request.get_json()
    return data['challenge']

Una vez que el proveedor verifique tu propiedad, también deberás agregar autorización de tu parte.

Autoriza solicitudes

Un destino del webhook es una URL abierta y pública. La mayoría de los servicios proporcionan un token o un secreto para garantizar que las solicitudes entrantes provengan de servicios autorizados. Debido a que la URL es pública, no puedes evitar los intentos maliciosos de enviar datos al destino del webhook. Sin embargo, el uso de tokens o secretos garantiza que solo se procesen datos de fuentes autorizadas.

Para verificar la solicitud, puedes configurar los objetos Secret o almacenar tu copia del Secret como una variable de entorno o con algún tipo de sistema de administración de claves.

Cuando almacenas tu copia del Secret como una variable de entorno, cada solicitud debe tener un Secret o un token en los encabezados de solicitud o en la carga útil de JSON, y debes verificarlo para asegurarte de que la fuente sea válida.

def index():
    request_secret = request.headers['Secret']
    if request_secret != os.environ['SECRET']:
        return ('Unauthorized', 401)

Si el proveedor de webhooks no admite un secreto ni otro mecanismo de autenticación, cualquier persona con la URL del destino del webhook podrá enviar mensajes. En este caso, la implementación del webhook debería ser segura de exponer en la Internet pública.

Responde a solicitudes

La mayoría de los servicios requieren que respondas a una solicitud dentro de un período determinado, según lo especificado por el servicio. Algunos webhooks tienen métodos de reintento integrados si hay una respuesta de error, como un código de estado HTTP 4xx o 5xx, por lo que deberás mostrar un código de estado exitoso (2xx) para informarle al servicio que el evento se procesó de forma correcta.

def index():
    data = request.get_json()
    return ('', 200)

Tiempos de espera

Knative serving y el proveedor de webhooks tienen tiempos de espera. Se aplicará el más corto a tu aplicación. Si el procesamiento de datos supera el tiempo que le asigna Knative serving o el proveedor de webhooks, deberás usar un producto que te permita completar el procesamiento de forma asíncrona, como Pub/Sub o Cloud Tasks. Estos productos te permiten transferir los datos con rapidez, mostrar una respuesta correcta al proveedor de webhooks de inmediato y continuar con el procesamiento sin tiempo de espera. Estas también son buenas opciones para manejar fallas y reintentos.

Patrones de webhooks comunes

Tipo Ejemplos
Retransmisión de datos Enviar una notificación a través de Firebase Cloud Messaging cada vez que se llama al webhook.
Almacenamiento de datos Almacenar los datos en BigQuery para un análisis posterior.
Activación de acciones Realizar acciones en Dialogflow, publicar respuestas en Twitter o enviarlas al entorno de etapa de pruebas cada vez que se confirma un código nuevo en GitHub.

Próximos pasos