web-dev-qa-db-ja.com

RESTは楽観的同時実行制御にのみ制限されていますか？

環境

REST各リクエストが完全に独立しているアーキテクチャスタイルの無国籍のため、サーバーはクライアントに関する情報を決して保存しません。

したがって、どのクライアントがリソースのロックを取得するかをサーバーストアに要求するため、悲観的な同時実行制御は適していません。次に、Etagヘッダーを使用して、オプティミスティック並行性制御が使用されます。 （ところで、私がそこで尋ねたように https://stackoverflow.com/questions/30080634/concurrency-in-a-rest-api ）

問題

オプティミスティック並行性制御メカニズムの主な問題は、すべてのクライアントが常にすべての操作を実行できるようにすることです。

そして、RESTの無国籍原則を破ることなく、それを回避したいと思います。つまり、すべてのクライアントがいつでも操作を実行することはできません。

質問

私の考えでは、semi-optimistic同時実行制御メカニズムを使用すると、次のように可能になります。

  • クライアントはトークンを要求できます
  • 生成できるトークンは1つだけで、有効期間は限られています
  • リソースの操作を実行するには（[〜＃〜] post [〜＃〜]または[〜＃など） 〜] put [〜＃〜]）、クライアントはリクエストのボディ（またはヘッダー？）の一部としてこのトークンを与える必要があります。トークンを持たないクライアントは、これらの操作を実行できません。

1つのクライアントのみが一部の操作（トークンを取得したクライアント）を実行できることを除いて、楽観的同時実行制御と非常に似ています。「すべてのクライアントがすべての操作を実行できる」の反対です。

このメカニズムは、RESTアーキテクチャスタイルと互換性がありますか？制約に違反していますか？私はSOに質問するつもりでしたが、これはソフトウェア設計に関連するより高レベルの質問のようです。

designarchitecturerestconcurrency
9
AilurusFulgens

ユーザーインタラクションを待機している間は、リソースを決してロックしないでください（これまでにないように）。

ある時点で、一部のユーザーは長期週末に離陸し、重要なレコードをロックしたままにします。

ああ、でも、巧妙なタイムアウト/デッドロックの解決策があるので、それを起こさせないでしょう。その後、ある時点でこれはひどく間違った状態になり、ニースの「あなたのウィジェットが注文されました」というメッセージを受け取ったユーザーは、自分のウィジェットが配信されなかった理由を知るよう要求するヘルプデスクで叫んでいます。

ほとんどの人は、「別のユーザーがこのパーツを注文したばかりです」というメッセージに対処できます。

3
James Anderson

トークンの使用はAPIで非常に一般的です。これらのトークンは通常ヘッダーとして送信され、明確なライフサイクルがあります。たとえば、OAuthについて考えてみましょう。

プログラミング言語やフレームワークに関係なく、REST APIは似ています。

並行性を制限したいシナリオがいくつか考えられますが、そのうちの2つは次のとおりです。

  1. データベース行のように同じリソースを更新する複数のクライアント。たとえば、2つの同時要求、1つはレコードを削除し、もう1つは同じレコードを更新しようとします。データベースとその設定方法によっては、データが異なるか存在しないため、レコードがロックされるか、無効な操作が行われる可能性があります。

  2. APIで特別なアクションを実行するスーパーユーザーまたは管理者。

これらの場合はどうしますか？

  1. データベースのトランザクション、シングルトン、ロック、および同様のメカニズムを使用して、リソースへのアクセスを同期します。

  2. トークンは機能するかもしれませんが、クライアント自体に関する情報だけを保存しない方が良いと思います。 1つのステップでユーザーを検証し、トークンを割り当てることができます。次に、トークンが有効で有効であることを確認します。復号化できるトークンを使用して、追加情報を取得します。これが特別なトークンである場合は保存して、一度にのみ許可することができます。この方法では、ユーザーではなくトークンを検証します。

これがお役に立てば幸いです。

2
Pablo Granados

RESTだけでは、あまりにも原始的です。 RESTを使い始めることもできますが、最終的には、リッチアプリケーションには結合を伴うクエリとトランザクションを伴う更新が必要になります。これらを独自に追加しようとするすべての開発者は、エラーが発生しやすく、一貫性がありません。幸いなことに、それを行うODataと呼ばれる新しい標準があります。 RESTの上に階層化され、（1）ナビゲーションプロパティを使用して単純な結合を可能にするクエリ言語を提供します（外部キーを公開する必要がない）、および（2）アトミック変更を含むバッチ処理セット。

（1）についてはこちらをご覧ください https://stackoverflow.com/a/3921423/471129 、および

ここと（2）を参照 https://stackoverflow.com/a/21939972/471129

0
Erik Eidt