http HEAD対GETパフォーマンス

YESまたはNOをできるだけ速く回答する必要があるREST Webサービスをセットアップしています。

HEADサービスを設計することは、それを行うための最良の方法のようですが、GETリクエストを実行するよりも実際に時間を稼ぐことができるかどうかを知りたいです。

サーバーでボディストリームが開いたり閉じたりしないようになっていると思います（約1ミリ秒？）。返されるバイト数は非常に少ないので、IPパケット番号でトランスポートの時間を確保できますか？

ご返信いただきありがとうございます。

編集：

コンテキストをさらに説明するには：

• 一部のプロセスを実行するRESTサービスのセットがあります（それらがアクティブな状態の場合）。
• これらすべての最初のサービスの状態を示す別のRESTサービスがあります。

その最後のサービスは非常に大規模なクライアントのセットによって非常に頻繁に呼び出されるため（5msごとに1回の呼び出しが予想される）、HEADメソッドの使用が価値ある最適化になり得るかどうか疑問に思っていましたか？レスポンス本文では約250文字が返されます。HEADメソッドは少なくともこれらの250文字の輸送を獲得しますが、その影響は何ですか？

呼び出しを1000回実行して、2つの方法（HEADとGET）の違いをベンチマークしようとしましたが、まったく効果がありません（<1ms）...

RESTful URIはサーバーの「リソース」を表す必要があります。多くの場合、リソースはデータベース内のレコードまたはファイルシステム上のファイルとして保存されます。リソースが大きいか、サーバーでの取得が遅い場合を除いて、のHEAD代わりにを使用しても、測定可能な向上が見られない場合がありますGET。メタデータの取得は、リソース全体の取得よりも高速ではない可能性があります。

両方のオプションを実装し、それらをベンチマークしてどちらが速いかを確認できますが、マイクロ最適化ではなく、理想的なRESTインターフェースの設計に焦点を当てます。クリーンなREST APIは、通常、高速である場合とそうでない場合があるkludgey APIよりも長期的にはより価値があります。の使用を推奨しているのではなくHEAD、「正しい」デザインである場合にのみ使用することをお勧めします。

本当に必要な情報が、HTTPヘッダーで適切に表現できるリソースに関するメタデータである場合、またはリソースが存在するかどうかを確認する場合、 HEADうまく機能する可能性があります。

たとえば、リソース123が存在するかどうかを確認するとします。200手段「はい」と404「いいえ」とは：

HEAD /resources/123 HTTP/1.1
[...]

HTTP/1.1 404 Not Found
[...]

ただし、RESTサービスに必要な「はい」または「いいえ」がメタデータではなくリソース自体の一部である場合は、を使用する必要がありますGET。

リクエスタが尋ねたのと同じ質問を探しているときに、私はこの返信を見つけました。私はこれもhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec9.htmlで見つけました：

HEADメソッドは、サーバーが応答でメッセージ本文を返してはならないことを除いて、GETと同じです。HEADリクエストへの応答でHTTPヘッダーに含まれるメタ情報は、GETリクエストへの応答で送信される情報と同一である必要があります（SHOULD）。このメソッドは、エンティティ本体自体を転送せずに、要求によって暗示されるエンティティに関するメタ情報を取得するために使用できます。この方法は、ハイパーテキストリンクの有効性、アクセシビリティ、および最近の変更をテストするためによく使用されます。

リクエスタの質問への正しい答えは、RESTプロトコルによって表されるものに依存するということだと私には思われるでしょう。たとえば、私の特定のケースでは、私のRESTプロトコルを使用して、かなり大きな（10Kを超えるような）画像を取得します。このようなリソースが常にチェックされていて、リクエストヘッダーを利用している場合、w3.orgの推奨事項に従い、HEADリクエストを使用することは理にかなっています。

私はこの種のアプローチを強くお勧めしません。

RESTfulサービスは、HTTP動詞のセマンティクスを尊重する必要があります。GET動詞はリソースのコンテンツを取得することを目的としていますが、HEAD動詞はコンテンツを返さないため、たとえば、リソースが変更されたかどうかを確認したり、リソースのサイズやタイプを確認したり、リソースを確認したりできます。存在します。

そして覚えておいてください：初期の最適化はすべての悪の根源です。

GETリクエストの代わりにHEADリクエストを使用しても、パフォーマンスはほとんど変わりません。

さらに、RESTフルでデータを取得したい場合は、HEADリクエストの代わりにGETリクエストを使用する必要があります。

GETはヘッド+ボディをフェッチし、HEADはヘッドのみをフェッチします。どちらが速いかは問題ではありません。私は上記の賛成投票の答えを理解していません。META情報を探している場合は、この目的のためのHEADを探してください。

「ボディストリームが開いている/閉じている」という懸念を理解できません。応答本文は、http応答ヘッダーと同じストリーム上にあり、2番目の接続を作成しません（ちなみに、これは3〜6ミリ秒の範囲です）。

これは、重要な、または測定可能な違いをもたらさないものに対する非常に時期尚早の最適化の試みのようです。実際の違いは、一般にRESTへの準拠です。GETを使用してデータを取得することをお勧めします。

私の答えは「いいえ」です。意味がある場合はGETを使用してください。HEADを使用してもパフォーマンスは向上しません。

HEADリクエストは、応答の本文が空であることを除いて、GETリクエストと同じです。この種類のリクエストは、必要なのがファイルに関するメタデータだけで、ファイルのすべてのデータを転送する必要がない場合に使用できます。

小さなテストを簡単に行って、パフォーマンスを自分で測定できます。本文で「Y」または「N」のみを返す場合は、すでに開いているストリームに追加された単一の追加バイトであるため、パフォーマンスの違いは無視できると思います。

それはより正しいので、私はGETにも行きます。HTTPヘッダーのコンテンツを返すのではなく、メタデータのみを返すことになっています。