19

次のシナリオを想定します。Web アプリケーションが RESTful API を介してリソースを提供します。多くのクライアントがこの API を使用します。目標は、クライアント上のデータを Web アプリケーションと (双方向で) 同期した状態に保つことです。

これを行う最も簡単な方法は、クライアントが最後に API と同期してから変更されたリソースがあるかどうかを API に問い合わせることです。これは、クライアントがタイムスタンプを伴う適切なリソースを API に要求する必要があることを意味します (データを更新する必要があるかどうかを確認するため)。これは、帯域幅の不必要な消費という点で、オーバーヘッドが最小のアプローチのように思えます。

ただし、このアプローチには、設計と責任の点でいくつかの欠点があると感じています。たとえば、API は、リソースが古くなっているかどうかのチェックに対処する必要はありません。API の唯一の責任は、更新の側面に対処する必要なく、要求されたときにリソースを提供することであるように思われます。この 2 番目のアプローチに従うと、クライアントは、データを更新して Web アプリケーションとの同期を維持する必要があるたびに、大量のデータを要求します。つまり、クライアントは、返されたデータがローカルに保存されたデータよりも新しいかどうかを確認します。このプロセスが数分おきに行われると、システムに大きな負荷がかかる可能性があります。

私はこれを正しく見ていますか、それとも見落としている中道がありますか?

4

1 に答える 1

24

これはかなり一般的な問題であり、RESTful なアプローチが解決に役立ちます。HTTP (通常、RESTful サービスの構築に使用されるアプリケーション プロトコル) は、API クライアントとサーバー側のデータとの同期を維持するために使用できるさまざまな手法をサポートしています。

クライアントが HTTP 応答でLast-Modifiedまたはヘッダーを受信した場合、その情報を使用して、将来的に条件付き GET呼び出しを行うことができます。これにより、サーバーは、クライアントが以前に保存したリソースの表現がまだ有効で正確であることを応答ですばやく示すことができます。これにより、サーバー (または中間プロキシまたはキャッシュ サーバー) がクライアントの要求に応答する方法が可能な限り効率的になり、コストのかかるバックエンド データ ストアへのラウンドトリップが削減される可能性があります。E-Tag304 – Not Modified

応答にLast-Modifiedヘッダーが含まれており、クライアントがそれで利用可能なパフォーマンスの最適化を利用したい場合If-Modified-Since、同じ URI への後続の GET 呼び出しにディレクティブを含め、受信した同じタイムスタンプ値を渡す必要があります。これにより、サーバーは、信頼できるバックエンド ソースから情報が変更されたことがわかっている場合にのみ、その情報を取得するように指示されます。もちろん、サーバーはこの手法をサポートするように構築する必要があります。

同様の原則がE-Tagヘッダーにも適用されます。anE-Tagは、特定の時点でのリソースの特定の状態を表す単純なハッシュ コードです。リソースが何らかの形で変化すると、そのE-Tag価値も変化します。クライアントがE-Tag応答に を見つけた場合、後続の GET 要求でそれを同じ URI に渡す必要があります。これにより、クライアントがリソースの最新の表現を持っているかどうかをサーバーがすばやく判断できるようになります。

最後に、クライアントがサーバーに対して発行する GET 要求の繰り返し回数を減らすために、おそらくロング ポーリング手法を検討する必要があります。本質的には、サーバー データの変更を監視するためにサーバーに非常に長い GET 要求を発行するのが秘訣です。データが変更されるか、非常に長いタイムアウトが発生するまで、GET は応答を返しません。後者の場合、クライアントは変更を再度監視するために同じ長期間有効な要求を再発行するだけです。アプローチが似ているComet や Web Sockets などのトピックも参照してください。

于 2012-08-01T17:12:28.657 に答える