file_get_contentsとHTTP_Request、どっちがいい?

file_get_contentsは、ラクチンかつ便利です。
引数にURLを指定して、変数に代入すればあらびっくり。
変数にURLで指定した先のファイルの中身が入ってます。


一方、豊富なオプションが魅力のHTTP_Request
その代わり、file_get_contentsのように1行ではすみません。


どっちを使うべきでしょう?



file_get_contentsでも色々指定できる

マニュアルを読む限り、フラグやオフセット位置、読み込むデータの最大バイト数ぐらいしか指定できないようにみえます。


PHP: file_get_contents - Manual
 http://php.net/manual/ja/function.file-get-contents.php



しかしコンテキストリソース(context)を使うことで、methodやheaderを指定できるそうです。
コンテキストリソースってそうやって使うんですね……。


さすがにこうなると1行で済むわけではありません。
しかしfile_get_contents、なめちゃいけないってことです。


file_get_contents で外部リソースにアクセスする 〜VirtualHost編〜
 (BUKURO-JIN)
 http://blog.y-110.net/log/eid151.html


PHP: stream_context_create - Manual
 http://php.net/manual/ja/function.stream-context-create.php


ファイルが存在するか確認するときはHTTP_Request。速いのもHTTP_Request?

以前、画像ファイルの存否を確認する方法を検討した、HTTP_Request
HTTPのレスポンスコードを使う場合には、file_get_contentsでは処理しきれないので、最初からレスポンスコードの評価の仕組みを揃えているHTTP_Requestを使うことになります。


ここで、file_get_contentsHTTP_Requestの速度を比較した記事を紹介します。


▽URLが存在するか調べる(OASIS)
 http://pochi.orz.ne.jp/oasis/archive_148.htm



もちろん、実際にファイルを取得するfile_get_contentsと、それをせずに済むHTTP_Requestでは、後者が速い。……それは当たり前です。しかしここまで違うとは思わなかったので、数字で見せてくれるのはありがたいです。ありがとうございます。


そして注目したいのは、通常のGETリクエストの場合でもHTTP_Requestの方が速いこと。
複数回実行したわけではないし、1割弱以上違うのですから、そういう結論になるんじゃないかなぁと。
私自身で再検証したわけではないので自信はありませんが。


エラー処理を考えるとHTTP_Request

速度を考えると、HTTP_Requestという結論になりそうですが、エラー処理の点からも根拠づけられそうです。


取得先がWebサーバということは、回線や負荷のタイミングによって状態が頻繁に変わるんですよね。つまり無視できないほどの確率でエラーのレスポンスコードを返してくるわけですよ。
どんなエラーでもとりあえず、返ってきたデータを取得できればいい、というのであれば、file_get_contentsでもいいですが、あまりそういうことは考えにくいですよね。


そうするとHTTP_Requestか。
1行でかける簡便さから、つい何も考えずfile_get_contentsを多用してしまったのですが、エラーをどうやって処理するかも考えて選択しなければいけませんね。



以上の結論は、書き上げた後、外部のエラーをどうやって処理しようかなぁと悩んだ末でした。


@を使って表示だけできないようにすればいいや、というのも頭をよぎりました。
しかしどうしても想像もつかないようなエラーを未然に対処するため、予防のために使うならともかく、こういう時に逃げで使ってはいけないだろうなぁと考えたわけです。
HTTP_Requestを使えばいいことに思い至った時は、当たり前じゃん!と頭痛がしたものです。とりあえず反省の意味も込めて、検討の結果を書いておきました。