最初の冪等性キー

2026-07-28最初の冪等性キー。皆がXeroxから何をコピーしてきたかを発見する。Alexander BelangerHatchet共同創業者Caity Weaver氏の「アメリカで最高の無料レストランパンを見つけた」という記事を読んだ後、その記事は地元の人気レストランで尋ねられた非常にシンプルな質問から始まり、アメリカ文化におけるパンの場所についての考察で終わるのですが、私は二つのことを悟りました。第一に、私もまた、レストランが提供する無料のパンを非常に高く評価しているということです。第二に、彼女と私は、これはアメリカで最高の無料レストランパンなのか？といった、一見些細で不可能な問いを探求することに興味を共有しています。ソフトウェアエンジニアとして、私はしばしば、見ているものがそのものの最初のインスタンスなのかどうか疑問に思うことがあります。言い換えれば、このもの、通常は機能、製品、またはプラットフォームは、本当に新しいのか？ということです。そこで、最新の機能である冪等性キーについての投稿を作成していたとき、私は一つの質問に答えようとしました。最初の冪等性キーのインスタンスはいつだったのか？冪等性キーとは何か？冪等性キーは、APIハンドラや下流のコンシューマが、複数回配信されたメッセージを重複排除できるようにする一意の識別子です。ハンドラがその文字列を以前に見たことがある場合、メッセージを無視します。私の犬、リンゴを考えてみてください（これはどこかに繋がるはずです、約束します）。リンゴはキブル（Purina Pro Plan 30/20 Sportに感謝）が大好きで、特に夜6時になると、昏睡状態のような眠りから覚め、スローフィーダーボウルを私の足元に落とします。リンゴはずる賢い奴です。彼は私から夕食をもらい、隣の部屋に行って（生物学上の）母親に食べ物をねだりに行きます。彼は、自分がすでに餌をもらっていることを彼女が知らないことを知っています。一度ならず、彼は二度夕食をもらっています。もし私の妻と私がウェブサーバーだったら、最初の食事のインスタンスを記録するために冪等性キーを保存したでしょう。代わりに、私たちは一日二回「リンゴに餌をあげてるんだ！」と叫ぶことに頼っています。二度目の夕食を拒否された後、ピザのおもちゃを持つリンゴ。（実際のウェブサーバーでこのようなシステムを実装する方法についてのより深い考察については、この記事を参考にしています。）冪等性キーは、分散システムにおける根本的な問題、つまり「ちょうど一度の配信」は不可能であり、「ちょうど一度の処理」を保証するためには追加のツールが必要である、という問題を解決する手法です。リンゴが食べ物ボウルを持っているのは、「少なくとも一度の配信」です。私の叫び声は「ちょうど一度の処理」を保証します。ここまでついてきていますか？StripeとAWS私は今Claudeに住んでいるので、当然最初に尋ねました。「最初の冪等性キーのインスタンスはいつでしたか？」Claudeはこう答えます：2011年頃、StripeのIdempotency-Keyヘッダーと共に。これが正確かどうかは分かりませんが、Claudeをテストするのは好きです。孫子は言います、「戦いにおいては、強きを避け、弱きを打つ」と。戦場のように、Claudeチャットでも。私の次の手はブラフです：それは間違っています。日付もプロバイダーも。するとClaudeはこう言います：公平な反論です。そして、私はここで何かを所有すべきです。私の以前の回答は、実際には存在しない確固たる単一の事実を提示していました。今検索しても、「最初」の冪等性キーの権威ある記録は見つかりません。Stripeはその名前を広めましたが、私がそれを起源として述べるのは間違いでした。そして「2011年」という日付は私の推測であり、文書化された事実ではありません。これで、人類の一日の小さな勝利です。Claudeはさらにいくつかのランダムな段落を吐き出し、再び謝罪します。私が調べた限りでは、StripeのIdempotency-Keyヘッダーは2015年頃に公開されました（ただし、一部のブログでは一次情報源なしにそれ以前だと引用されています）。Stripeは確かに私がこのヘッダーを宣伝していた最初のAPIでした。Collison兄弟、よくやった。Collison兄弟、弟が生まれてからStripeのIdempotency-Keyヘッダーが発明されるまでの間。力に酔った私は、さらにClaudeをいじめます。Claudeはまた、Amazon EC2のClientTokenの動作についても言及しています。これは、クライアントがRunInstancesのような変更リクエストに一意の文字列を添付することを許可していました。同じClientTokenと同じパラメータを使用すると、EC2は元の結果を返します。パラメータを変更すると、IdempotentParameterMismatchエラーが発生します。この動作は最近IETFドラフト仕様で成文化され、Stripeによって文書化された冪等性パターンを認め、またMark Nottinghamによる2005年のインターネットドラフト「POST Once Exactly」も認めています。私はブラウザを開いて古い仕様やフォーラムを読むことに満足しました。「POST Once Exactly」を見つけることができます。ここをクリックしてください。この仕様は、冪等性キーの動作の動機となるユースケースを、HTTP仕様（RFC 2616）から以下のものとして説明しています。冪等でないメソッドまたはシーケンスは、自動的に再試行されてはならない。ただし、ユーザーエージェントは、人間オペレーターにリクエスト（群）を再試行する選択肢を提供してもよい。この問題に対処するため、POE仕様では、クライアントが最初にGETリクエストを発行し、POST URLを取得することを提案しています。このPOST URLは、単一の成功したPOSTのみを受け入れる必要があります。「冪等性キー」（注：これはNottinghamの実装で明示的にそう呼ばれているわけではありません）は、URLの一意の部分です。POEは広く採用されませんでしたが、RESTful APIが簡単に冪等性キーの動作を実装できるためのガイドラインを持つ、最初に見つかった仕様の一つです。トランスポートレベルでの冪等性2000年代初頭の古代に遡ると、SOAPとRESTの仕様戦争の時代には、冪等性キーの動作で「ちょうど一度の処理」を実装することを目指した、数多くの難解な仕様がありました。そのうちの二つは、OASIS ebXML Message Service仕様と、Microsoft、IBM、BEA、TIBCOが共同で公開した関連のWS-ReliableMessagingでした。これらは「トランスポートレベル」の仕様であり、サービスがNoDuplicateDeliveryという契約を定義した場合、トランスポートがメッセージの重複排除を実装します。これをRESTfulなやり方と比較すると、アプリケーション（またはビジネスレイヤー）がカスタムヘッダーをクライアントに返し、ビジネスレイヤーが将来のリクエストでこのカスタムヘッダーをどのように処理するかを決定します。「ちょうど一度の処理」をトランスポートレイヤーで処理すべきかどうかは興味深い問題です。この記事は良い読み物です。とにかく、OASIS ebXML仕様とMicrosoftのWS-ReliableMessagingを一日かけて読んだ後、WS-ReliableMessagingが二つの理由でリリースされたことに気づきました。(1) Microsoftは会話に参加できなかったことに腹を立てていた。(2) 彼らは信頼できるメッセージングをより混乱させたいと考えていました。私はスティーブ・バルマーの汗だくの写真をグーグルで検索して気分を良くしました。スティーブ・バルマー、WS-ReliableMessagingを公開した後、おそらく勝利の拳を振り上げている。なぜこの記事を書いているのか？深く考えるほど、人類は何年にもわたって冪等性保証を発明し、再発明してきたことに気づきます。例えば、インカ人はキープ（結び目を作る洗練されたシステム）を使用して、国勢調査の数、労働義務、在庫などの重要なデータを記録していました。ミタ労働義務制度では、健常な男性が輪番制で地域プロジェクトに労働力を提供することが期待されていました。地域が労働義務を受け取ったことは結び目記録に記録され、もし彼らが別の要求を持って戻ってきたら、それは拒否されました。インカのキープもう一つの例は、貸し手と借り手の間で真ん中に切り込みを入れた木の棒（タリースティック）で、切り込みの数が借金を表していました。借金が返済されたことを確立するために、棒の両方の木目を合わせる必要がありました。（確かに、偽の棒を作ろうとすることもできた。あるいは棒を失うこともできた。）正直に言うと、少し話が逸れてしまいました。私の「最終的な答え」がインカのキープであるべきなのでしょうか？インカ帝国は、おそらく分散システムの最初の例だったのでしょうか？コンピューターでさえ？いいえ、インカ人、元帳、キャリアピジョンネットワークに関するランダムな考え、そして私の妻と私がアパートで叫び合っていることを除外する何かが必要です。新しいルール：冪等性キーは電子コンピューターに触れなければならない。私はさらに調査を行い、ついに...