El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Por qué las API que solo usan webhooks excluyen discretamente a quienes trabajan por lotes
Un webhook tiene sentido para un evento cuyo momento no puedes prever: un pago que se confirma, un cambio en el estado de un envío, algo que ocurre en el lado del proveedor y a lo que tu sistema tiene que reaccionar cuando suceda. Tiene mucho menos sentido como única forma de obtener la respuesta a una pregunta que hiciste directamente y a la que esperas una respuesta directa, como resolver una dirección o consultar una zona horaria. Exigir un endpoint de webhook solo para recibir el resultado de una consulta síncrona traslada un trabajo real de infraestructura a un cliente que quizá solo quiere ejecutar un script, esperar una respuesta y seguir con lo suyo.
Esto se convierte en un problema mayor en concreto para los casos de uso por lotes y masivos. Un desarrollador que ejecuta un script puntual para resolver una lista de direcciones de una hoja de cálculo no quiere montar un receptor de webhooks, gestionar reintentos si su endpoint deja de estar accesible un momento y relacionar las cargas de webhook entrantes con las solicitudes originales, todo para obtener respuestas que podrían haber llegado directamente en la respuesta a la llamada que las pidió. Para este tipo de tarea, la entrega solo por webhook añade toda una capa de infraestructura a algo que debería ser una sola solicitud y una sola respuesta.
Tratamos las consultas, incluidas las de lotes y masivas, como síncronas por defecto: envías la solicitud y recibes la respuesta directamente, tanto si esa solicitud contiene un elemento como mil. Usar un endpoint de lotes no exige montar un receptor público solo para recoger los resultados. Un script, una tarea cron o una herramienta puntual de línea de comandos puede llamar al endpoint y usar la respuesta de inmediato, igual que funcionaría una consulta individual.
El diseño basado solo en webhooks suele venir de una arquitectura construida en torno al procesamiento asíncrono en el lado del proveedor, donde un gran trabajo por lotes tarda de verdad un tiempo considerable en completarse internamente, y un webhook es realmente la forma más natural de avisar de que ha terminado. Es un patrón legítimo para algunos tipos de procesamiento a gran escala o con mucha cola. Se convierte en un problema cuando es la única opción ofrecida, y obliga a todos los casos de uso, incluidos los que preferirían esperar un momento y obtener una respuesta directa, a encajar en una arquitectura diseñada para otro tipo de carga de trabajo más lenta.
No estamos en contra de que los webhooks existan como opción para trabajos realmente largos o asíncronos. Estamos en contra de hacerlos obligatorios para tareas que no necesitan ser asíncronas en absoluto. Un script que quiere enviar mil consultas y recibir mil respuestas debería poder hacer exactamente eso, en una llamada y una respuesta, sin tener que construir antes una infraestructura para recibir una devolución de llamada en una tarea que una solicitud síncrona habría resuelto igual de bien, con mucho menos código.