3 ms·

Personally if I was getting data from HTTP in PHP the last thing I would ever do is use file_get_contents. Just because you can doesn't mean you should. It's g

Personally if I was getting data from HTTP in PHP the last thing I would ever do is use file_get_contents. Just because you can doesn't mean you should. It's generally advised to set allow_url_include to off which would make this code not work. Also if you're mention curl in your technical article about code you should ask yourself why your code isn't using the curl integration in the language you're using. Putting a "You are doing it wrong" in your title is just asking for people to point out everything that is wrong with it.

DaveRandom 12y ago
cURL has it's problems - one of them being a different kind of hateful API, another being the fact that you still need to actually configure it properly, which means you have to be approximately competent. A major element of the 5.6 changes (documented in an article not yet written, but should be by early next week) is to protect Jimmy the junior dev from himself - chances are that an inexperienced dev, given the choice between a one-liner and several lines with a bunch of scary-looking options, is going to pick the former. I'm not advocating it, just stating it.
TazeTSchnitzel 12y ago
>Personally if I was getting data from HTTP in PHP the last thing I would ever do is use file_get_contents. Just because you can doesn't mean you should. Why not? file_get_contents makes things much simpler, and there's nothing really wrong with it. Fetching a JSON file is simple, for example: $file = file_get_contents("http://example.com/some.json"); if ($file === FALSE) { die("Failed to get JSON file"); } $data = json_decode($file); if ($data === NULL) { die("Failed to decode JSON"); } echo htmlspecialchars($data->foo->bar); To be honest, I think cURL is unnecessary in most cases. PHP's HTTP streams do a better job without relying on an additional extension (HTTP streams are in the PHP core, while cURL must be built separately and often installed separately), and the HTTP stream context options with their string key names are much nicer than the dreaded CURLOPT_* constants.
- johnnyfaehell 12y ago
  Why not? 1) The name of the function is file_get_contents, however you're not getting a file. It just annoys me, it reads wrong. stream_get_contents is better but I still wouldn't go reaching for streams for HTTP requests. 2) It provides you with a lack of control. 3) It's pretty sloppy, to do anything like POST requests with bodies you have to do hacky stuff. I wouldn't be writing my own curl call request either I would use a library such as Guzzle.
  - TazeTSchnitzel 12y ago
    >1) The name of the function is file_get_contents, however you're not getting a file. No, you are getting a file. It's from a remote location, but it's a file nonetheless. Are ftp:// resources not files? Are ssh:// resources not files? >2) It provides you with a lack of control. Does it? Stream context options give you a degree of control. If file_get_contents isn't quite right for you, there's also fopen. >3) It's pretty sloppy, to do anything like POST requests with bodies you have to do hacky stuff. $ctx = stream_context_create([ 'http' => [ 'method' => 'POST', 'header' => 'Content-type: application/x-www-form-urlencoded', 'content' => $some_post_data_here ] ]); $result = file_get_contents('http://example.com/post_endpoint', false, $ctx); Where's the hacky stuff? It's also shorter and more readable than the equivalent in cURL (the PHP cURL extension, not the command-line, obviously) and you don't even need to install an extension!
    - johnnyfaehell 12y ago
      > No, you are getting a file. It's from a remote location, but it's a file nonetheless. Are ftp:// resources not files? Are ssh:// resources not files? FTP of course it's a file, it's a FILE TRANSFER PROTOCOL. HTTP is HYPERTEXT TRANSFER PROTOCOL. You're getting Hypertext. SSH:// are not files. You are getting the contents of a stream. So you're getting the stream content. > Does it? Stream context options give you a degree of control. If file_get_contents isn't quite right for you, there's also fopen. To be fair I've not looked into all the options for the streams in http. But does it give you the option to use global dns cache? How about save the cookies and reuse them for later requests? Will it deal with gzip for me? If you can do all the stuff curl can do I'll be all fair enough you've got a point. > Where's the hacky stuff? For me the fact I had to define the header. > It's also shorter and more readable than the equivalent in cURL It's not more readable. It says it's getting a file, you lied to me and got stream contents instead. > and you don't even need to install an extension! If you really don't want to install extensions and just use the core language fair enough, I would rather use the best tools available.

DaveRandom 12y ago

cURL has it's problems - one of them being a different kind of hateful API, another being the fact that you still need to actually configure it properly, which means you have to be approximately competent. A major element of the 5.6 changes (documented in an article not yet written, but should be by early next week) is to protect Jimmy the junior dev from himself - chances are that an inexperienced dev, given the choice between a one-liner and several lines with a bunch of scary-looking options, is going to pick the former. I'm not advocating it, just stating it.

TazeTSchnitzel 12y ago

>Personally if I was getting data from HTTP in PHP the last thing I would ever do is use file_get_contents. Just because you can doesn't mean you should. Why not? file_get_contents makes things much simpler, and there's nothing really wrong with it. Fetching a JSON file is simple, for example: $file = file_get_contents("http://example.com/some.json"); if ($file === FALSE) { die("Failed to get JSON file"); } $data = json_decode($file); if ($data === NULL) { die("Failed to decode JSON"); } echo htmlspecialchars($data->foo->bar); To be honest, I think cURL is unnecessary in most cases. PHP's HTTP streams do a better job without relying on an additional extension (HTTP streams are in the PHP core, while cURL must be built separately and often installed separately), and the HTTP stream context options with their string key names are much nicer than the dreaded CURLOPT_* constants.

johnnyfaehell 12y ago
Why not? 1) The name of the function is file_get_contents, however you're not getting a file. It just annoys me, it reads wrong. stream_get_contents is better but I still wouldn't go reaching for streams for HTTP requests. 2) It provides you with a lack of control. 3) It's pretty sloppy, to do anything like POST requests with bodies you have to do hacky stuff. I wouldn't be writing my own curl call request either I would use a library such as Guzzle.
- TazeTSchnitzel 12y ago
  >1) The name of the function is file_get_contents, however you're not getting a file. No, you are getting a file. It's from a remote location, but it's a file nonetheless. Are ftp:// resources not files? Are ssh:// resources not files? >2) It provides you with a lack of control. Does it? Stream context options give you a degree of control. If file_get_contents isn't quite right for you, there's also fopen. >3) It's pretty sloppy, to do anything like POST requests with bodies you have to do hacky stuff. $ctx = stream_context_create([ 'http' => [ 'method' => 'POST', 'header' => 'Content-type: application/x-www-form-urlencoded', 'content' => $some_post_data_here ] ]); $result = file_get_contents('http://example.com/post_endpoint', false, $ctx); Where's the hacky stuff? It's also shorter and more readable than the equivalent in cURL (the PHP cURL extension, not the command-line, obviously) and you don't even need to install an extension!
  - johnnyfaehell 12y ago
    > No, you are getting a file. It's from a remote location, but it's a file nonetheless. Are ftp:// resources not files? Are ssh:// resources not files? FTP of course it's a file, it's a FILE TRANSFER PROTOCOL. HTTP is HYPERTEXT TRANSFER PROTOCOL. You're getting Hypertext. SSH:// are not files. You are getting the contents of a stream. So you're getting the stream content. > Does it? Stream context options give you a degree of control. If file_get_contents isn't quite right for you, there's also fopen. To be fair I've not looked into all the options for the streams in http. But does it give you the option to use global dns cache? How about save the cookies and reuse them for later requests? Will it deal with gzip for me? If you can do all the stuff curl can do I'll be all fair enough you've got a point. > Where's the hacky stuff? For me the fact I had to define the header. > It's also shorter and more readable than the equivalent in cURL It's not more readable. It says it's getting a file, you lied to me and got stream contents instead. > and you don't even need to install an extension! If you really don't want to install extensions and just use the core language fair enough, I would rather use the best tools available.