[解決済み] httpのHEADとGETのパフォーマンス

質問

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

HEADサービスを設計することは、それを行うための最良の方法のように思えますが、私は、GETリクエストを行うことに対して、本当にいくつかの時間を得ることができるかどうかを知りたいと思います。

私は、私のサーバ上でオープン/クローズされないボディストリームを得ると仮定します（約1ミリ秒?） 返すバイトの量は非常に少ないので、私は、IPパケット番号のトランスポートで時間を得るのでしょうか？

あなたの応答に前もって感謝します!

編集してください。

さらに文脈を説明すると

• 私は、一連のRESTサービスを持っていて、それらがアクティブな状態であれば、いくつかのプロセスを実行します。
• これらすべての最初のサービスの状態を示す別のRESTサービスを持っています。

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

私は2つの方法（HEAD対GET）の違いをベンチマークしようとし、1000回の呼び出しを実行しましたが、全く利得を見ません（< 1ms）...。

どのように解決するのですか？

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

両方のオプションを実装して、どちらが速いかベンチマークすることもできますが、マイクロ最適化するよりも、私は理想的な REST インターフェースを設計することに集中します。クリーンな REST API は、通常、高速であるかどうかにかかわらず、つぎはぎの API よりも長い目で見て価値があります。私は、REST API を使用することを奨励しているわけではありません。 HEAD ただ、それが正しい設計である場合にのみ使用することをお勧めします。

本当に必要な情報が、HTTPヘッダでうまく表現できるリソースに関するメタデータである場合、またはリソースが存在するかどうかをチェックする場合。 HEAD はうまく機能するかもしれません。

例えば、リソース123が存在するかどうかをチェックしたいとします。A 200 は yes" を意味し 404 は"no"を意味します。

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

HTTP/1.1 404 Not Found
[...]

しかし、REST サービスに必要な "yes" または "no" が、メタデータではなく、リソース自体の一部である場合、次のように使用します。 GET .