はじめに

この記事では、冪等演算が何であるか、なぜ冪等性が有用であるかを見ていき、RESTでの冪等性を見ていきます。

冪等とは何ですか？簡単に言えば、結果を変更せずに冪等演算を複数回実行できます。

さらに、操作は、最初の正常な実行後に副作用を引き起こしてはなりません。

二つの簡単な例を見てみましょう。2.1.

絶対値

絶対値を返す関数は冪等であり、同じ数にどれくらいの頻度で適用しても、常に同じ結果を返します。p>

次に、次のことが当てはまります。

例：

対照的に、数値の符号を反転する関数は冪等ではありません。

then:

例:p>

2.2。 べき乗演算のもう一つの実用的な例は、システム内のユーザーの連絡先の詳細を更新することです。 電話番号のみを更新するとしましょう。 この更新プログラムの副作用は、新しい番号に確認コードを含むテキストメッセージを送信することです。 次の3つのシナリオが考えられます。

• 最初の更新メッセージが正常に処理され、システム内で番号が更新され、テキストメッセージが送信されました。 更新メッセージが再び送信されると、何も起こりません。 また、テキストメッセージは二度目には送信されません。
• 最初の更新が失敗します。 システムは更新されず、テキストメッセージは送信されません。 2回目の更新が成功すると、システムが更新され、テキストメッセージが送信されます。
• 最初の更新が失敗します。 別の更新が送信される前に、ユーザーはシステムで無効になります。 システムの状態が変更されたため、電話番号の2回目の更新は影響を受けません。

なぜ冪等？

冪等性は、同じ要求が同じシステム状態につながることを保証し、意図せずに複数回実行されるアクションはありません。例として、支払いサービスPSを介して受信者Rにお金を送るための送信者Sからの要求を見てみましょう。

3.1。 非冪等の例

要求の冪等でないバージョンは次のとおりです。

最初の試行では、Sは$10をRに送信する要求を送信します。PSはメッ PS sendsは、ネットワーク障害のためにそのメッセージを受信しないsにエラーメッセージを返します。

Sは転送が成功したかどうかを知らないので、彼は再び試みます。 ここでも、確認は失敗し、Sは転送が成功したかどうかを知りません。

したがって、彼は三度目の試みをします。 PSはメッセージを受信し、それを新しい要求とみなし、お金をRに送信し、確認をSに返します。これは、同じ支払いを再試行して2回送信しないことを意図していたため、冪等リクエストではありません。3.2.

3.2. 冪等キー

支払いは、冪等が有用である理由を説明するための良い例です。 前の例では、転送がすでに成功していることを知らずにSが退職するため、Rへの支払いが複数回実行されることがわかりました。操作が冪等であった場合、これはそうではありませんでした。 しかし、PSは、Sが同じ支払いを再試行しただけで、Sにsecond10の2回目の支払いを送信したくないことをどのように知っていますか？これを実現するために、SはPSへの要求に冪等キーを含みます。 このキーは、例えば、UUIDであることができます。 PSが同じ冪等キーを持つ要求を受信した場合、それは再試行であることを認識します。 以前にキーを見たことがない場合は、それが新しい要求であることを知っています。

前の例の冪等バージョンを見てみましょう。

ここで、最初の試行と最初の再試行は、要求に冪等キー（この例では65TH68M5）が含まれていることを除いて、

重要な違いは、2回目の再試行です: PSはメッセージを受信し、同じ冪等キーを持つメッセージがすでに正常に処理されたことを検出し、rにお金を再度送信せずにsに確認を返します。ここで、冪等性の利点は、Sが二重支払いを心配することなく、彼が望むように何度でも再試行できることです。

ここで、冪等性の利点は、Sが二重支払を気にせずに何度でも再試行できることです。 PSは、メッセージを受信していない場合にSが再試行できることを知っているので、Sが確認を受信することを心配する必要はありません。このアプローチの欠点は、PSが受信したすべてのキーを格納する必要があることです。 多くの要求がない場合、これは問題ないかもしれません; ただし、要求頻度が非常に高い場合は、問題が発生する可能性があります。 解決策は、いくつかの時間後に冪等キーを期限切れにすることができます。

冪等と残り

4.1. Rest APIを構築するときに理解することが重要な、冪等性がHTTP動詞にどのように適用されるかを簡単に見てみましょう。 すべてのHTTP動詞の非常に詳細な参照は、RFC7231で見つけることができます。次の表は、どの動詞が冪等である（またはすべきである）かを示しています。

次の表は、どの動詞が冪等であるかを示しています。

4.2。 冪等演算

GET、HEAD、およびOPTIONは、データのみを読み取るため、明らかに冪等ですが、リソースの作成、更新、削除は行いません。putは、リソースを更新するか、存在しない場合は新しいリソースを作成するため、冪等です。 同じ更新を複数回送信した場合、リソースは変更されません。4.3.

非冪等演算

POSTは、新しいリソースを作成し、再び呼び出された場合、通常は別のリソースを作成するため、冪等である必要はありません。 しかし、それは冪等演算としても実装することができます。

パッチ操作はリソースを部分的に更新し、必ずしも冪等である必要はありません。 PUTとPATCHの違いをよりよく理解するための例を見てみましょう。

オンラインショップのショッピングカートにアイテムを追加したいとしましょう。 PUTを使用する場合は、すでにカートに入っているすべてのアイテムを含む完全なショッピングカートデータを送信する必要があります。 PATCHを使用すると、追加するアイテムのみを送信することができ、カートに既にあるアイテムのリストに追加されます。

パッチリクエストを再度送信すると、同じアイテムが再び追加されます。 もちろん、POSTに関しては、冪等パッチを実装することもできます。

4.4. 冪等演算へのいくつかの呼び出しが必ずしも同じHTTP応答になるとは限らないことに注意することが重要です。たとえば、putは、リソースが作成された場合は201（作成済み）を返し、リソースが更新された場合は200（OK）または203（コンテンツなし）を返します。たとえば、DELETEは、実際の削除が行われたときに200（OK）または204（コンテンツなし）を返すことができます。 それ以降の呼び出しでは、404(Not found)が返されます。この記事では、冪等が何を意味するのか、冪等の利点は何か、そしてそれがRESTとどのように関係するのかを見ました。冪等の一般的な意味は理解しやすいですが、APIの設計中に副作用やHTTP応答などのすべての微妙な点を考慮するのは非常に難しい場合があります。