1

私はRESTfulWebAPIを設計しようとしているので、rfc2616を研究してきました。私は楽観的同時実行性のためにETagを使用するというアイデアが好きで、競合状態なしでリソースを追加する安全な方法を作るためにそれを使用しようとしていました。しかし、セクション14.24で次の2つのステートメントに気づきました。

リクエストがIf-Matchヘッダーフィールドなしで2xxまたは412ステータス以外の結果になる場合は、If-Matchヘッダーを無視する必要があります。

リソース（PUTなど）を更新することを目的としたリクエストには、If-Match値に対応するエンティティ（単一のエンティティタグ）がなくなった場合にリクエストメソッドを適用してはならないことを通知するIf-Matchヘッダーフィールドを含めることができます（MAY）。そのリソースの表現。

私はRDBMSを使用していますが、トランザクションを試すまでトランザクションが正常にコミットされるかどうかわからないため、最初の要件は少し面倒だと思います。誰かがETagが一致しないヘッダーを提供した場合を考えてみましょIf-Matchう。コミットが成功した場合は、ヘッダーに注意しIf-Match、コミットを試みずに412を返す必要があります。コミットが失敗した場合、If-Matchヘッダーのないリクエストは結果として発生します。非2XX/412応答なので、If-Matchヘッダーを無視する必要があります。つまり、コミットを試行する必要があります。

私が理解できる限り、私には2つの選択肢があります。

  1. 2フェーズコミットを使用して、コミットを試行する前にコミットが成功するかどうかを予測します。
  2. 上記の最初の要件を無視し、無視If-Matchすると2XX/412以外の応答が発生した場合でも412を返します。（これは私が傾いているものです）

他のアイデアはありますか？仕様を誤解していますか？

4

2 に答える 2

3

「変更しない限り更新」（楽観的ロック）のようなものは機能しませんか？エンティティは、バージョン番号またはetagをデータベースに保存する必要があります。

  1. コミットを必要としない検証を実行し、etagを無視し、必要に応じてエラーを返します

  2. id =：the_idおよびetag =：expected_etagであるエンティティを更新します

  3. これにより、影響を受ける行に対して0または1が返されます

  4. 0の場合、リソースは同時更新を確認しました（または、IDが完全に間違っているため、個別に確認できます）。この場合、412を返します

  5. 専念

  6. コミットが失敗した場合は、必要に応じてエラーを返します

于 2012-08-06T01:09:13.750 に答える
0

これは理論的な側面かもしれませんが、HTTP仕様に関する現在の理解に基づいて、If-Matchのようなヘッダーの使用法を、安全な方法を除いて実際には使用できないものに分類します。これは次の理由によるものです。

「リクエストが、If-Matchヘッダーフィールドなしで、2xxまたは412ステータス以外の結果になる場合は、If-Matchヘッダーを無視する必要があります」。

なんで？ほとんどの場合、要求が実行された場合に何が起こるかを予測することは不可能であるという理由だけで。

例として、実行する必要のあるコードで発生するIOレベルのエラーまたは例外的なケースを誰が予測できますか？

2xxと412に5xxを追加すると、より「解決可能」になります。

于 2013-04-30T09:54:09.990 に答える