httpリクエストをバッチ処理する標準的な方法を知っている人はいますか? 意味 - 1 回の往復で複数の http アトミック リクエストを送信しますか?
パフォーマンス上の理由から、REST API 実装にそのようなメカニズムが必要です。この種のメカニズムにより、クライアントが API を使用するために実行する必要があるラウンド トリップの回数を大幅に減らすことができます。
前もって感謝します、
シェイ
httpリクエストをバッチ処理する標準的な方法を知っている人はいますか? 意味 - 1 回の往復で複数の http アトミック リクエストを送信しますか?
パフォーマンス上の理由から、REST API 実装にそのようなメカニズムが必要です。この種のメカニズムにより、クライアントが API を使用するために実行する必要があるラウンド トリップの回数を大幅に減らすことができます。
前もって感謝します、
シェイ
HTTP Pipeliningと呼ばれる公式の HTTP の方法があります。ただし、サーバー側よりもブラウザ側で問題が発生する可能性があります。そのため、クライアント側のみで高度な制御ができる場合に使用できる可能性があります。
XHR は常にパイプリングを許可するとは限りません。また、知る限り、Javascript を使用した HTTP トンネリングを制御することはできません。したがって、基本的な ajax-jQuery 実装は存在しません。しかし、Comet と Bayeux プロトコルを使用して、双方向の長期 tcp 接続をエミュレートする高度な機能を見つけることができます。これにより、tcp ラウンドトリップが確実に減少します。
私はコメットの専門家ではありませんが、このコメット & HTTP パイプリングの記事で有益な情報を見つけることができるかもしれません。私の理解では、これのほとんどは非常に実験的なものですが、HTTP パイプラインが使用されている場合、少なくとも「古典的な」コメットを使用して適切なフォールバックを行うことができます。利用不可。これには、再タグ付けまたは新しい質問が必要になる場合があります。
クライアントが必要とするデータを含む新しいリソースを定義します。http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743を参照してください。
これは REST の問題です。それらはエンティティ レベルにあります。REST の考え方は、各 URL がリソースを一意に識別するようにすることです。もちろん、集約されたリソースを導入できます。たとえば、www.yoursite.com/customerA?include=Orders,Faults,Incidents これは、CustomerA の XML を返しますが、顧客の注文、障害、インシデントも埋め込みコレクションとして返します。
REST ベースのサービスまたは何らかの API を見ている場合。ここに標準のいくつかの始まりがありますhttp://www.odata.org/documentation/odata-version-3-0/batch-processing/
Google による実装はこちらhttps://cloud.google.com/storage/docs/json_api/v1/how-tos/batch