有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
Webhook専用のAPIが一括処理のユーザーを知らず知らず締め出す理由
Webhookが理にかなっているのは、タイミングを予測できないイベントの場合です。支払いの完了、配送状況の変化など、プロバイダー側で起きたことに対して、発生したときにいつでもシステムが反応する必要があるものです。一方、住所の解決やタイムゾーンの検索のように、直接尋ねて直接の答えを期待する質問に答えを得る唯一の方法としては、はるかに理にかなっていません。同期的な検索の結果を受け取るためだけにWebhookのエンドポイントを要求すると、スクリプトを実行してレスポンスを待ち、次に進みたいだけかもしれないお客様に、実際のインフラ作業を押し付けることになります。
これは、特にバッチや一括処理の用途で大きな問題になります。スプレッドシートの住所リストを解決するために使い捨てのスクリプトを実行する開発者は、Webhookの受信側を立ち上げ、エンドポイントが一時的に到達できない場合の再試行を処理し、受信したWebhookのペイロードを元のリクエストに対応付けたいとは思いません。しかもそれは、答えを求めた呼び出しのレスポンスで直接返ってきたはずの答えを得るためだけなのです。この種のタスクをWebhookのみで配信すると、1回のリクエストと1回のレスポンスで済むはずのタスクに、インフラの層がまるごと1つ追加されます。
当社は、バッチや一括処理を含む検索を、デフォルトで同期的に扱っています。リクエストを送れば、そのリクエストに含まれるのが1件でも1,000件でも、答えが直接返ってきます。バッチのエンドポイントを使うために、結果を受け取るためだけに外部公開の受信側を立ち上げる必要はまったくありません。スクリプト、cronジョブ、使い捨てのコマンドラインツールからエンドポイントを呼び出し、単一の検索と同じようにレスポンスをすぐに使うことができます。
Webhookのみの設計は、多くの場合、プロバイダー側の非同期処理を中心に作られたアーキテクチャから生まれます。そこでは大きなバッチジョブが内部で完了するまでに実際にかなりの時間がかかり、Webhookは完了を知らせる方法として本当に自然なものです。これは、ある種の大規模な処理や大量にキューイングされる処理にとっては正当なパターンです。問題になるのは、それが唯一の選択肢として提供され、少し待って直接答えを得たいだけの用途も含め、あらゆる用途が、別の、より遅い種類のワークロード向けに設計されたアーキテクチャに押し込まれる場合です。
当社は、本当に長時間かかる処理や非同期の処理のための選択肢としてWebhookが存在することには反対していません。反対しているのは、非同期である必要がまったくないタスクにWebhookを必須にすることです。1,000件の検索を送って1,000件の答えを受け取りたいスクリプトは、まさにそのとおりに、1回の呼び出しと1回のレスポンスで実行できるべきです。同期的なリクエストでも同じようにうまく、しかもはるかに少ないコードで処理できたはずのタスクのために、まずコールバックを受け取るインフラを構築する必要があってはなりません。