10

RESTful API の同時実行の問題をどのように解決するのか興味があります。より具体的には、手動での検査と更新が必要なオブジェクトのコレクションがあります。たとえば、列を手動で更新する必要がある多数の行です。ただし、API を多数のクライアントに公開すると、すべてのクライアントがこれらのアイテムを上から下に取得するため、多くのユーザーが同じ行の列を同時に埋めることになります。私は衝突がないようにしたいと思っています。シンプルでステートフルな方法は、アイテムをサービスのキューにダンプし、人々が要求したときにそれらをポップすることです。

これのステートレス バージョンは何ですか? IP アドレスでハッシュするか、ID に基づいて行をランダムに取得しますか?

：： アップデート ：：

「えっと、クライアントから見れば単純にステートレスじゃないですか？

それは確かに非常に理にかなっています。RESTful API に関する記事 (ibm.com/developerworks/webservices/library/ws-restful) を読んでいて、ページングについて少し触れた後、非常にステートフルなキューが 1 ページずつインクリメントするようなものではないかと心配しましたが、 「次のページ」はクライアント側で相対的であるため、実際にはかなり異なりますが、「ポップ」はクライアントにとって常にステートレスです。以前に何がポップされたかは関係ありません。

頭をすっきりさせてくれてありがとう！」 - 私

4

3 に答える 3

5

次の 2 つの基本的な方法があります。

  1. 完全にステートレスになり、「最後のリクエストが勝つ」戦略を採用します。奇妙に聞こえるかもしれませんが、予測可能性、スケーラビリティ、コードの複雑さ、およびクライアント側とサーバー側の両方での実装の点で、おそらく最もクリーンなソリューションです。また、多くの優先順位があります。Google のようなサイトが、start=10for page 2、start=20for page 3 などを使用してクエリを介してページ分割する方法を見てください。

    ページ間を行ったり来たりすると、ページ内のコンテンツが変化することに気付くかもしれません。ユーザーは常に最新の情報を取得しており、Google は多くのサーバーのいずれかでリクエストを処理できます。セッション情報を検索して最後のクエリ コンテキストが何であったかを判断する必要はありません。

    このアプローチの最大の利点は、サーバーの実装が単純であることです。各リクエストはバックエンドのデータ レイヤーを通過するだけでよく、HTTP レベル (E-Tag または Last-Modified ヘッダー経由) とサーバー側 (memcache などを使用) の両方でキャッシュするのに最適です。例）。

  2. ステートフルになり、API「セッション」ごとにサーバーにクライアントごとのロックまたはトークンを発行させる方法を見つけてください。これは、棒で海の潮流と戦おうとするようなものです。失敗してイライラすることになるからです。

    どのようにクライアントを識別しますか? セッションキー? IPアドレス？彼らが乗ったソケットのファイル記述子（リクエスト間で接続を閉じることができるHTTPのようなトランスポートを使用している場合は幸運です...）？このために選択した詳細は、サーバー側で永続化する必要があります。または、アプリサーバーで厄介な古いスティッキーセッション機能を使用する必要があります (そうであれば、クライアントが使用しているサーバーがダウンした場合にクライアントを助けることができます)セッションの途中）。

    不意に姿を消した API クライアントをどのように処理しますか? リーパー スレッドにアイドル スレッドをクリーンアップさせることで、セッション ロックを自動的にタイムアウトにしますか? これにより、コードが増え、複雑になり、バグが隠れる場所が増えます。長いアイドル時間から戻ってきて、期限切れのロックを再利用しようとする API クライアントについてはどうすればよいでしょうか? そのような状況を処理するには、クライアント アプリケーションをどのように構築すればよいでしょうか?

私は続けることができますが、うまくいけばあなたは私の要点を理解することができます. オプション 1 を使用して、ステートレスにします。そうしないと、サーバー側でクライアントの状態を追跡しようとすることになります。クライアントの状態を追跡する必要があるのは、クライアント自体だけです。

于 2012-03-25T02:30:53.603 に答える
1

リソースの状態を維持しても問題ありません。「ステートレス禁止」は、セッション状態を参照するだけです。

以下は、 Roy Fielding の影響力のある REST 派生からの抜粋です。

次に、クライアントとサーバーの相互作用に制約を追加します。通信は、セクション 3.4.3 (図 5-3) のクライアント-ステートレス-サーバー (CSS) スタイルのように、本質的にステートレスでなければなりません。サーバーには、要求を理解するために必要なすべての情報が含まれている必要があり、サーバーに保存されているコンテキストを利用することはできません。したがって、セッション状態は完全にクライアント上に保持されます。

于 2013-06-01T23:14:30.643 に答える