http HEAD vs GETパフォーマンス
私は、できるだけ早くYESまたはNOに答える必要があるREST Webサービスをセットアップしています。
HEADサービスを設計するのが最善の方法のように思えますが、GETリクエストを行うよりも本当に時間を稼ぐかどうかを知りたいです。
私は、サーバー上でボディーストリームを開いたり閉じたりしないようにします（約1ミリ秒？）。返されるバイト数が非常に少ないので、IPパケット番号で転送中に時間を稼ぐことができますか？
ご回答ありがとうございます！
編集：
コンテキストをさらに説明するには：
- いくつかのプロセスがアクティブな状態にある場合、それらを実行するRESTサービスのセットがあります。
- これらすべての最初のサービスの状態を示す別のRESTサービスがあります。
その最後のサービスは非常に多くのクライアントセットによって頻繁に呼び出されるため（5ミリ秒ごとに1回の呼び出しが予想されます）、HEADメソッドを使用することが価値のある最適化になるかどうか疑問に思いました。約250文字が応答本文に返されます。 HEADメソッドは少なくともこれらの250文字のトランスポートを獲得しますが、その影響は何ですか？
私は2回の方法（HEADとGET）の違いをベンチマークしようとしましたが、呼び出しの1000倍を実行しましたが、まったくゲインがありません（<1ms）...
RESTful URIは、サーバーの「リソース」を表す必要があります。リソースは、多くの場合、データベースまたはファイルシステム上のファイルにレコードとして保存されます。リソースが大きいか、サーバーでの取得が遅い場合を除き、HEADの代わりにGETを使用しても、測定可能なゲインが表示されない場合があります。メタデータの取得は、リソース全体の取得よりも速くない可能性があります。
両方のオプションを実装し、どちらを高速化するかをベンチマークすることができますが、マイクロ最適化ではなく、理想的なRESTインターフェースの設計に焦点を当てます。通常、クリーンなREST APIは、高速である場合とそうでない場合がある、粗末な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要求への応答で送信された情報と同一である必要があります。このメソッドは、エンティティ本体自体を転送せずに、リクエストによって暗示されるエンティティに関するメタ情報を取得するために使用できます。このメソッドは、ハイパーテキストリンクの有効性、アクセシビリティ、最近の変更をテストするためによく使用されます。
リクエスタの質問に対する正しい答えは、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を使用してデータを取得することをお勧めします。
私の答えはNOです。意味があればGETを使用してください。HEADを使用してもパフォーマンスは向上しません。
HEADリクエストはGETリクエストと同じですが、レスポンスの本文が空です。この種類のリクエストは、ファイルに関するメタデータだけが必要な場合に使用できますが、ファイルのすべてのデータを転送する必要はありません。
簡単なテストを行って、自分でパフォーマンスを測定できます。ボディで「Y」または「N」のみを返す場合、それはすでに開いているストリームに追加される単一の余分なバイトであるため、パフォーマンスの違いは無視できると思います。
GETの方が正しいので、これも使用します。 HTTPヘッダーでコンテンツを返すのではなく、メタデータのみを返します。