On 14 October 2014 14:57, Kris Craig <kris.cr...@gmail.com> wrote: > On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright <c...@daverandom.com> wrote: > >> On 14 October 2014 14:46, Kris Craig <kris.cr...@gmail.com> wrote: >> > On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan <m...@mjdugan.com> wrote: >> > >> >> >> >> On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: >> >> >> >> >> >> On 14 Oct 2014, at 14:27, Kristopher <kristopherwil...@gmail.com> >> wrote: >> >> >> >> > $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. >> >> >> >> Ew, non-superglobals. >> >> >> >> But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY >> >> (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes >> >> sense, but isn’t too long: >> >> >> >> * $_QUERY - query string parameters >> >> * $_BODY - request body parameters >> >> * $_REQUEST - query string and request body parameters >> >> >> >> Makes more sense than $_GET and $_POST. >> >> >> >> Any objections? >> >> >> >> -- >> >> Andrea Faulds >> >> http://ajf.me/ >> >> >> >> >> >> +1 for this. This would hopefully also eliminate the confusion for new >> >> developers (or not-so-new developers) who don’t quite understand that >> $_GET >> >> and $_POST don’t strictly relate to their HTTP verbs of the same name. >> >> >> >> -- >> >> >> >> Mike Dugan >> >> >> >> m...@mjdugan.com >> >> >> > >> > That could work, though the BC breakage will be extreme. I'm not sure if >> > that's worth it even in a major version increment. On the other hand, >> > making $_PUT and $_DELETE available wouldn't break anything and wouldn't >> > require re-training for devs. >> >> ...but is also the wrong solution. It's not scalable, > > > How is it not scalable, exactly? It's just a couple aliases.
Because in a few years when the FOO request method has become commonplace we will get requests to add support for $_FOO, and then $_BAR, and the $_CHEESE... where does it end? > >> and the only >> sensible way to implement them would be as aliases of $_POST, because >> they would contain the same data. How does this fundamentally differ >> from $_BODY (or whatever)? >> > > It's not supposed to functionally differ. It's supposed to create some > better consistency and make it easier for devs to differentiate between > different REST methods when retrieving data. If REQUEST_METHOD is PUT, > then I can set the parsed params to the value of $_PUT. The aliases match > the methods used, making the code that much more readable and scalable. This doesn't actually help anything, though, if anything it hinders it. You route your request based on the method, this way you would either have to couple the first layer after routing to the method by using a specific named superglobal at that layer, or have a switch/case, variable variable or some other nastiness at the top level to pick the right superglobal to the next layer. If the form data submitted by the request entity body - always in the same place in every HTTP request message - is always in the same data store at the PHP layer, there's an extra decision taken away. > --Kris To be brutally honest I see this as a discussion of highly questionable merit anyway, due to the fact that in the overwhelming majority of cases where the request method is not POST the entity body will not represent HTML form data - browsers don't make requests of these methods with the involvement of client-side scripting at the moment (or in the foreseeable future), the content type of the request body is *highly* unlikely to be something PHP would even attempt to decode. Sorry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
