4

Possible Duplicate:
What's wrong with using $_REQUEST[]?

My understanding is the PHP sets up $_REQUEST for both POST and GET request types. While building a restful api I'm using PUT and DELETE as well. Rather than create a new $PUT or $DELETE variable to store this in, is there any valid reason not to use $_REQUEST? I would think using the same mechanism, $_REQUEST, throughout all the code would be better, more readable and more understandable than using 2 or 3 mechanisms depending on request type.

By valid I mean answers like 'bad practice' aren't valid to me... why is it bad practice?

code: parse_str($request->data, $_REQUEST);

I've read Overwriting $_POST for PUT or DELETE requests but that would overwrite $_POST with PUT data, that to me would be wrong as $_POST is describing POST data not PUT data in the name of the variable. I also have read the answer there - create a accessor class. But this now leaves 2 mechanisms to access passed user date, the class and $_REQUEST.

Community
  • 1
  • 1
Justin808
  • 20,859
  • 46
  • 160
  • 265
  • `$_REQUEST` is an associative array that by default contains the contents of `$_GET`, `$_POST` **and** `$_COOKIE` unless [`variable_order`](http://php.net/manual/en/ini.core.php#ini.variables-order) modified the default. As of 5.3, it is populated in [`request_order`](http://php.net/manual/en/ini.core.php#ini.request-order). The ini settings can lead to `$_REQUEST` not containing what you expect, which is why you should use the proper superglobals instead. – Gordon Feb 26 '12 at 23:06

1 Answers1

1

Ignoring $_REQUEST and using an accessor class is the right thing to do. Simply don't use $_REQUEST, most people wouldn't because it be an inconsistent mess as the value of it depends on the request_order php.ini setting.

chx
  • 11,270
  • 7
  • 55
  • 129