Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Warum reine Webhook-APIs Batch-Nutzer stillschweigend ausschließen
Ein Webhook ist sinnvoll für ein Ereignis, dessen Zeitpunkt Sie nicht vorhersagen können: eine Zahlung, die abgewickelt wird, ein Sendungsstatus, der sich ändert, etwas, das auf der Seite des Anbieters passiert und auf das Ihr System reagieren muss, wann immer es eintritt. Deutlich weniger sinnvoll ist er als einziger Weg, eine Antwort auf eine Frage zu erhalten, die Sie direkt gestellt haben und auf die Sie eine direkte Antwort erwarten, etwa das Auflösen einer Adresse oder das Abfragen einer Zeitzone. Einen Webhook-Endpunkt zu verlangen, nur um das Ergebnis einer synchronen Abfrage zu empfangen, bürdet echte Infrastrukturarbeit einem Kunden auf, der vielleicht nur ein Skript ausführen, auf eine Antwort warten und weitermachen möchte.
Besonders bei Batch- und Massenanwendungen wird das zu einem größeren Problem. Ein Entwickler, der ein einmaliges Skript ausführt, um eine Liste von Adressen aus einer Tabelle aufzulösen, möchte keinen Webhook-Empfänger aufsetzen, keine Wiederholungsversuche behandeln, falls sein Endpunkt kurz nicht erreichbar ist, und keine eingehenden Webhook-Payloads den ursprünglichen Anfragen zuordnen, nur um Antworten zu erhalten, die direkt in der Antwort auf den Aufruf hätten zurückkommen können, der sie angefordert hat. Die reine Webhook-Zustellung fügt einer solchen Aufgabe eine ganze Infrastrukturschicht hinzu, obwohl sie aus einer einzigen Anfrage und einer einzigen Antwort bestehen sollte.
Wir behandeln Abfragen, auch Batch- und Massenabfragen, standardmäßig synchron: Sie senden die Anfrage und erhalten die Antwort direkt zurück, ob diese Anfrage ein Element enthält oder tausend. Nichts an der Nutzung eines Batch-Endpunkts erfordert, einen öffentlich erreichbaren Empfänger aufzusetzen, nur um Ergebnisse einzusammeln. Ein Skript, ein Cronjob oder ein einmaliges Kommandozeilenwerkzeug kann den Endpunkt aufrufen und die Antwort sofort verwenden, genau wie bei einer einzelnen Abfrage.
Ein reines Webhook-Design entsteht meist aus einer Architektur, die auf der Seite des Anbieters auf asynchrone Verarbeitung ausgelegt ist, wo ein großer Batch-Job intern tatsächlich spürbar Zeit braucht und ein Webhook wirklich der natürlichere Weg ist, den Abschluss zu melden. Für manche Arten groß angelegter oder stark in Warteschlangen verarbeiteter Aufgaben ist das ein legitimes Muster. Zum Problem wird es, wenn es die einzige angebotene Option ist und jeden Anwendungsfall, auch jene, die lieber kurz warten und direkt eine Antwort bekommen würden, in eine Architektur zwingt, die für eine andere, langsamere Art von Arbeitslast entworfen wurde.
Wir haben nichts dagegen, dass es Webhooks als Option für wirklich lang laufende oder asynchrone Arbeit gibt. Wir sind dagegen, sie für Aufgaben vorzuschreiben, die überhaupt nicht asynchron sein müssen. Ein Skript, das tausend Abfragen senden und tausend Antworten zurückbekommen will, sollte genau das tun können, in einem Aufruf und einer Antwort, ohne zuerst Infrastruktur aufzubauen, um einen Callback für eine Aufgabe zu empfangen, die eine synchrone Anfrage genauso gut und mit viel weniger Code erledigt hätte.