ディレクトリ
インターフェイスの冪等の意味
元々数学意味冪等性は、同一の線形変換の結果とN番目の変換の表現です。
冪等でのRESTfulなAPIは、一回またはN回生成されたリソースの結果に影響を与えるメソッドを呼び出す指し同じですが、特別な注意が必要である：ここで冪等は、生成されたリソースの結果の影響を指し、代わりにHTTPメソッドを呼び出した結果を返します。
たとえば、GETメソッドRESTfulなAPIは、クエリのリソース情報であることが冪等に沿ったものであるので、リソースへの影響を持っていませんが、結果は、各コールGETメソッドの戻りは、おそらく（プロパティリソース異なる場合があります他のメソッドを呼び出す前に、GETメソッド）に変更されました。
実際にはRESTfulなインターフェースのための分散型アーキテクチャのみならず、APIの冪等が、インターフェイスはすべてのタイプに適しており、呼び出し回またはN回のインターフェイスは、リソースの結果に影響を与える際に確保するために同じです。
インターフェイスは冪等どのような使用を遵守します
冪等のインタフェースに関係なく、衝撃の回またはN倍リソースのコールがある場合に非常に有用である、同じであることを保証します。
例えば、そのようなインタフェースの方法がある：有料（長いアカウント、int型金 ）、 銀行デビットカードでのお支払いに使用する方法、アカウントIDのアカウントパラメータは、お金が必要な金額から控除されます。ユーザがWebから支払うためにボタンをクリックすると、あなたは、メソッドの実装ロジックに指定口座から対応する商品の価格を控除する必要があります。支払い操作が正常に実行されていますが、何らかの理由でクライアントへの応答メッセージを返すために失敗した場合は、この時点で支払われた場合、ユーザーエクスペリエンスへのこの時間は、成功のお支払いになりそうではない方法を実行するために、再度、もう一度ボタンをクリックしてください結果は一つだけのアイテムを購入することをユーザーにつながる可能性があり、それはもちろん無理がある二重のお金を取りました。以下に示すように全体のプロセス：
もちろん、上記の例のシナリオ、重複支払いを避けるために、ユーザは、など、他の手段によって解決することができます：分散トランザクション、または支払い状況などに基づいてヒントを与えるようにユーザに促します。
しかし、分散トランザクションの導入、それは実装の複雑さをもたらすでしょうが、また、インターフェイスのパフォーマンスに影響を与える場合、かつ迅速な方法を取ると、ユーザーが支払いを重複していないことを確認していない百パーセントために、一定のリスクがあります。そして、インタフェース、すなわち、冪等に適合していた場合：だけでなく、から、分散トランザクションの複雑さを紹介する、次にどちらの必要性、サービス側の両方が、最初の段落バックルだろうことを保証するために、一回または複数の支払いを行っているかどうか、同じ賃金の注文を基本的に重複して支払いの問題を解決するため、これは、インタフェースが値の冪等を遵守しています。
すべてのすべてで、冪等に沿って、インターフェースはシステム実装の複雑さを軽減することができ、かつ国家資源の一貫性を確保します。
このような電力およびHTTPメソッドのセキュリティなど
HTTPプロトコルのRESTfulスタイル方法の性質に使用されるインタフェースの設計は、従って、RESTfulなインターフェース法などのパワーが冪等HTTPメソッドを指します。
HTTPメソッドコモン：OPTIONS（サーバー情報を取得するために）、HEAD（要求リソースヘッダ情報）、（リソースへのアクセス）をGET、POST（リソースを作成する）、PUT（更新リソースのすべての情報）は、パッチ（更新されたリソース区間情報）、DELETE （リソースを削除します）。だから、これらの冪等HTTPメソッドと、それをどのような？
付加冪等に加えて、安全手段は、変更されたリソースを生成するHTTPメソッドを行います。
以下は、HTTPや安全要約として電力の一般的に使用される方法です。
| HTTPメソッド名 | 冪等かどうか | それは安全なの？ |
|---|---|---|
| OPTIONS | と | と |
| 頭 | と | と |
| 取得する | と | と |
| プット | と | N |
| DELETE | と | N |
| 役職 | N | N |
| パッチ | N | N |
上記の表からわかるように、冪等とセキュリティHTTPメソッドは、それぞれのセキュリティ方式の解釈冪等であり、以下、同じ概念ではありません。
- OPTIONSメソッドは、多くの場合、サーバー情報を取得するために使用され、リソースへの影響はありません、またそれは冪等が安全であるように、リソースは、変更されます。OPTIONSメソッドは、クロスドメインの中で最も一般的なシナリオは、ブラウザを要求していますブラウザがクロスドメインアクセス（それがGETメソッドまたはPOSTメソッドであるかどうか）、その後、POSTメソッドは、サーバーから情報を取得する前にOPTIONSメソッドを送信し、GETかの実際のビジネスを送信するAPIを立ち上げている場合は、サーバーから取得した情報が返されます要求は、次のステップが正常に実際のサービス要求を送信するかどうかを決定するためには、クロスドメインアクセスをサポートするかどうかを知っています。
- ヘッダ情報のHEADメソッド、リソース要求は、リソースには影響しません、またそれが安全であるべき等となるように、リソースが変更されます。
- GETメソッドは、返された結果かもしれないが毎回同じではない、リソース情報を取得するために使用されるが、GETメソッド自体は、リソースへの影響を持っていない、それはGETメソッドでリソースを安らかなセマンティクスを変更しないので、それはまた、冪等でありますセキュリティ。
- それは意味論で安らかに冪等が、安全ではないので、コール回またはN回の結果が同じであるように、PUTメソッドは、更新するリソースの総量を表します。
- 結果は一回の呼び出しまたはN回が同じで、リソースを削除する方法をDELETE、その冪等が、安全ではありません。
- 安全ではないとしながら、POSTメソッドは、明らかに（新しいN資源N回を呼び出し、新しいリソース一度呼んで）異なるN回の呼び出しの結果で一度呼び出され、したがって、冪等されていない、安らかな意味論に新たなリソースを表し。
- それは冪等ではないので、：PATCHメソッドRESTfulなセマンティック資源の現地最新情報を示し、我々は同じ結果がN回（さまざまなバリエーションのコールの数の属性として更新されたリソースなど）を呼び出し、一度呼び出して保証することはできません同時に、それは安全ではありません。
インタフェースを設計する方法冪等を遵守
インターフェースの主要な設計は、そのリソースの影響は同じで、そのパワーと他のインターフェイスのいずれか回又はN回呼び出されることを保証することです。
上記の概要冪等HTTPメソッドから見て、HTTPプロトコルのPATCH POSTメソッドは冪等な性質ではない（しかし、私たちはしばしばRESTfulなインターフェースでそれらを使用する）ことができ、それはそれはPOSTすることはできません意味していPATCH及びそれのインターフェースを冪等するために設計された方法？答えはノー、明らかです。上記の例では、注文IDには、また、1つのメソッドのパラメータとして使用することができます：有料（長いアカウント、int型、お金 、長いため）、 そのサーバは一度だけ順番支払われることを確認してください（注文番号がグローバルに一意です）関係なく、一度呼び出されるメソッドの、又はN回の結果が同じで、それは、冪等のインターフェースを保証します。プロセス番号はサーバのみID一度実行されることを保証するように、当然のことながら、シーン内にない順序番号は、インタフェースは、メソッドのパラメータとしてプロセス番号、プロセス番号とIDのグローバルに一意なIDを生成するように動作することができます冪等のインターフェースを確保します。
次のようにコンプライアンス冪等インターフェースコールフローを説明します。
最後に書かれました
システムの複雑さを低減することができるいくつかのケースでは冪等性インタフェースを満たすように設計されているが（例えば：できない分散トランザクションの導入）インターフェースは、必要なときにすべての機会に冪等性によって問題を解決することはできないが、まだ我々は、分散トランザクション処理のようなフレームワークを導入する必要があります。私たちは、普遍的なソリューションとしてインタフェース冪等を持参していないが、我々は、インターフェースの設計が非常に貴重である冪等の治療に沿って検討してみてください。
【参考】
http://blog.720ui.com/2016/restful_idempotent/ RESTfulな冪等を理解するためにどのよう
https://www.cnblogs.com/weidagang2046/archive/2011/06/04/idempotence.htmlは、 HTTPの力を理解しますおよびその他の性的
https://sofish.github.io/restcookbook/http%20methods/idempotency/ RESTfulなマニュアル