WebサービスのAPIの冪等性についての説明を読み、分かったような分からないような気分になったので、自分の理解を整理する。

数学的な意味での冪等性

まず、前提知識。数学的な意味での関数における冪等性は明確。

モノイド MM の元 xx が冪等元であるとは、

xx=x x \cdot x = x

を満たすことである。

集合 XX 上の自己写像 f:XXf: X \to X の全体は、合成 \circ に関してモノイド XXX^X をなす。fXXf \in X^X が冪等元であるとは、ff がモノイド XXX^X における冪等元であること、すなわち

ff=f f \circ f = f

を満たすことである。

API 呼び出しにおける冪等性

これを踏まえて、Web サービスの API のような「外部から内部状態が更新でき、同時に結果がレスポンスとして観測できる」場合の冪等性を考えてみる。

RFC 9110: HTTP Semantics の 9.2.2. Idempotent Methods では、「操作を N 回行った場合にサーバーに引き起こされる意図された効果が、1 回行った場合と同じ」(訳は筆者)とされている。つまり、サーバーを状態空間 XX と見たとき XX 上に引き起こされる効果が同じ、ということであって、API を呼び出したときのレスポンスについては何も要請されていない、というのが自分の理解である。

XX を状態空間(サーバー)、SS をレスポンスの集合として、API を呼び出す行為は次のようにモデリングできると考えた。

g:XS×X,g(x)=(r(x),f(x)) g: X \to S \times X, \quad g(x) = (r(x), f(x))
  • f:XXf : X \to X — 状態空間の状態遷移
  • r:XSr : X \to S — レスポンスの(素朴な)モデル

rr についてはあくまで近似である。例えば現在時刻を返すようなレスポンスまでは表現しきれていないと思う。このモデルでは、観測可能なのは r(x)r(x) だけであり、更新後の状態 f(x)f(x) は直接観測できない。

最初、rr は更新後の状態の関数になるはずなので、観測しているのは r(f(x))r(f(x)) のように書けるかと思ったのだが、それだと更新前の値にも依存するようなレスポンスを返すクエリ(DELETE など)が表現できない。g(x)=(r(x),f(x))g(x) = (r(x), f(x)) のように「呼び出し時点の状態 xx」に対して rr を適用する形にすれば、この問題は起きない。

こう書いたとき、ffXXX^X の冪等元となることが冪等性の定義であり、rrgg そのものには冪等性を要求しない(そもそも rrr \circ r 等は定義できない)、というのが私の理解である。つまり、特定の条件を課さなければ、返ってくるレスポンスのみから冪等性は判定できない。

クエリパラメータを含めた一般化

RFC の定義は「同じ操作を N 回行った場合」という前提を置いている。つまり暗黙のうちにクエリ(リクエスト内容)は固定されている。これを明示するために、クエリの集合 RR を導入して、h:R×XS×Xh: R \times X \to S \times X と、クエリと状態からレスポンスと状態への写像として考えてみる。冪等性を考える場合は、クエリを1回目・2回目とも同じ aRa \in R に固定し、g~(x)=h(a,x)\tilde{g}(x) = h(a, x) とした上で、この g~\tilde{g} の状態成分(XX 側)が冪等元になっているかどうかを考えている。

単純に見えて自分が混乱していた例として、xx+1x \mapsto x+1 のように、レスポンスをそのまま次のクエリの入力として使い回すケースがある。上の h(a,x)h(a, x) の枠組みで言えば、これは2回目の呼び出しのクエリ aa が1回目の aa と違う値になっている、ということなので、そもそも g~(x)=h(a,x)\tilde{g}(x) = h(a,x)(同じ aa を固定した写像)の冪等性を論じる対象になっていない。

上の例を f:ZZf: \mathbb{Z} \to \mathbb{Z} という数学的な世界だけで考えれば当然合成は定義できるが、API に関して言えば、レスポンスの型 SS と状態の型 XX は別物なので、レスポンスをそのまま次の状態として代入し直せるとは限らない。今回はたまたま S=XS = X のようになっていて代入できてしまっているだけで、一般には常にできるわけではない。

レスポンスから ff の冪等性を確認できるか

もし rrff の結果だけに依存する形

r=r~f,r~:XS r = \tilde{r} \circ f, \qquad \tilde{r}: X \to S

に書けて、かつ r~\tilde{r} が単射であれば、1回目の観測 r(x)=r~(f(x))r(x) = \tilde{r}(f(x)) と2回目の観測 r(f(x))=r~(f(f(x)))r(f(x)) = \tilde{r}(f(f(x))) が一致することから、r~\tilde{r} の単射性より f(f(x))=f(x)f(f(x)) = f(x)、すなわち ff が冪等であることが確認できる。

ただし、この r~\tilde{r} が単射になるかどうかは API の設計に強く依存する。例えば PUT/GET のレスポンスとして更新後・現在のリソースをまるごと返すような API であれば、レスポンスから状態がほぼ復元できるので単射に近づく。一方、200/404 のようなステータスコードや {“success”: true} のようなフラグだけを返す API では、多くの状態が同じレスポンスに潰れてしまうため(多対一)、一般には単射にならない。

注意したいのは、レスポンスが JSON で一見リッチに見えても、それだけでは単射性は保証されないという点である。タイムスタンプや内部カウンタ、他のリソースとの関連など、レスポンスに載っていない隠れた内部状態が存在すれば、見た目上豊富な表現を返していても実は非単射、ということは普通に起こり得る。

State モナド

Haskell だと g(x)=(r(x),f(x))g(x) = (r(x), f(x))State モナドそのもの(State s a ≡ s -> (a, s)s が状態、a が戻り値)と(AI に)教えてもらった。興味深いが、Haskell およびモナドの正確な意味を理解しておらず、自分の言葉で説明できない。残念である。