140

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

HEAD サービスを設計するのが最善の方法のように思えますが、GET リクエストを実行するよりも実際に時間を節約できるかどうか知りたいです。

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

ご回答ありがとうございます。

編集：

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

  • アクティブな状態にある場合、いくつかのプロセスを実行する一連の REST サービスがあります。
  • これらすべての最初のサービスの状態を示す別の REST サービスがあります。

最後のサービスは、非常に多くのクライアントによって非常に頻繁に呼び出されるため (5 ミリ秒ごとに 1 回の呼び出しが予想される)、HEAD メソッドを使用することが価値のある最適化になるかどうか疑問に思っていました。約 250 文字が応答本文で返されます。HEAD メソッドは少なくともこれらの 250 文字のトランスポートを取得しますが、その影響は何ですか?

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

4

8 に答える 8

209

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

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

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

たとえば、リソース 123 が存在するかどうかを確認するとします。A200は「はい」を404意味し、A は「いいえ」を意味します。

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

HTTP/1.1 404 Not Found
[...]

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

于 2013-05-21T00:02:16.393 に答える
8

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

さらに、REST 対応にしたい場合やデータを GET したい場合は、HEAD リクエストではなく GET リクエストを使用する必要があります。

于 2013-05-16T16:23:27.990 に答える
3

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

これは、重要な、または測定可能な違いさえももたらさない、非常に時期尚早の最適化の試みのようです。本当の違いは、一般的に REST に準拠していることであり、GET を使用してデータを取得することを推奨しています。

私の答えは NO です。理にかなっている場合は GET を使用してください。HEAD を使用してもパフォーマンスは向上しません。

于 2013-05-22T13:17:35.963 に答える