18

アプリケーションのバックエンドと連携するために使用される REST API があります。競合防止機能を実装する必要があります。これは、編集要求 (POST/PUT) で、クライアントが最後に読み取ってから現在までにレコードが変更されていないかどうかを確認し、変更されている場合はクライアントに競合があることを通知します。

問題は、コンフリクト チェック タグ (タイムスタンプである可能性が最も高いですが、それを義務付けたくはありません) を送信する方法と、エラーを返す方法です。

可能な限り標準の REST パターンを使用したいので、ここで検討したソリューションは次のとおりです。

  • If-Modified-Since の使用。ここでの問題は、タイムスタンプの使用が義務付けられていることと、仕様では 412 を返さなければならないと述べていることです。仕様で説明されているように、編集の競合であることを示すために、より一般的なコードではなく、より具体的な 409 コードを返したいと考えています。412 他の理由で発生する可能性があります。これにより、専用のエラー コードが作成されるため、クライアントが編集の競合に対して特別な処理を行うことがはるかに容易になります。

  • If-Match の使用。添付された任意のデータを使用できるため、より優れていますが、仕様では、409 の方が適切であるにもかかわらず、412 を使用することが義務付けられています。また、仕様では If-Match が Etags にリンクされていることが示唆されており、すべてのレコードに対して適切な Etag を計算することは現実的ではないため、データに Etags を使用していません。レコード データの一部としてチェックに使用するタグがありますが、これは ETag として送信されず、既存のクライアントは ETag を処理しないため、可能であればクライアントにこの新しい要件を課したくありません。

  • カスタム X-Header の使用。これは問題なく機能し、クライアントが追加するのは非常に簡単ですが、可能であれば標準の REST 手段を使用することをお勧めします。

では、この場合の推奨される方法は何ですか? 標準の REST 手段を使用して 409 で応答し、すべてをきれいに処理する方法はありますか?

4

1 に答える 1

15

基本的にIf-*、ヘッダーに前提条件がある場合は、返す必要があります412。custom を使用したとしてもX-Header、それはヘッダーが返さなければならないという定義がないことを意味するだけ412です。カスタム ヘッダーが前提条件として使用されている場合は、412その定義に従って返す必要があります。

この応答コードにより、クライアントは現在のリソース メタ情報 (ヘッダー フィールド データ) に前提条件を設定できます...

E-TagIf-*通常、前提条件の一部としてリクエストでのみ送信されるため、必要な場合409は使用しませんE-Tag

を使用する場合409は、ヘッダーではなく、事前条件または事後条件をリクエスト本文に入れるだけです。WebDav は403、または409条件が失敗したときに戻ります。409クライアントがリクエストを修正できる可能性がある場合。RFC 3259 を参照してください

結論412として、前提条件がヘッダーにある場合は使用し、そうでない場合は を使用します409

于 2013-06-12T23:30:29.940 に答える