リソースを作成するためにREST POSTが使用されます。
HTTP POSTは多くのものに使用されます。 RESTは特に気にしません。一様なインターフェースとハイパーメディアをサポートするリソースが必要なだけです。
この時点でネットワークが
残念に失敗しました！
今何ですか？これはどうやって扱いますか？再試行は重複を作成するだけなので、簡単に作成をやり直すことはできません。
これはRESTに直接関係しない一般的なメッセージングの問題です。最も一般的な解決策は、Idempotent Receiverパターンを使用することです。要するに、 は、受信者が要求を既に完了したものとして認識するのに十分な情報を持つようにメッセージを定義する必要があります。
理想的には、これはbusiness levelでサポートされています。
等価の値の集合は、しばしば単純です。我々はちょうどリストよりもを設定すると思う必要があります。
多数のエンティティの集団はトリッキーです。要求に新しいエンティティの識別子が含まれている場合、または提供されたデータから要求を計算できる場合は、コレクションをハッシュと考えることができます。
これらのアプローチのいずれも適合しない場合、別の可能性があります。コレクションの等価な突然変異を実行する代わりに、コレクション自体の突然変異を冪等化します。 「比較して交換する」と考える - コレクションの現在の状態を識別するリクエスト情報をエンコードします。要求が到着したときに状態がまだ最新である場合、突然変異が適用されます。条件が成立しない場合、要求はノーオペレーションになります。
これをHTTPに変換すると、コレクションリソースを更新するためのプロトコルが少し変更されます。まず、現在の表現を取得します。メタデータでは、サーバーはサブクエリ要求で使用できるvalidatorsを提供します。バリデータを取得すると、クライアントはリソースの現在の表現を評価して、変更が必要かどうかを判断します。クライアントが変更を決定した場合、If-MatchまたはIf-Unmodified-Sinceヘッダー（バリデーターを含む）で変更を送信します。要求を処理する前にサーバーは、バリデータを考慮して、すぐに要求を放棄します。412 Precondition Failed。
したがって、条件付きの状態変更要求が失われた場合、クライアントはクライアントの意図を誤解することなく、クライアントが独自の裁量で要求を繰り返すことができます。