-- Mike Dugan m...@mjdugan.com On October 14, 2014 at 10:08:56 AM, Chris Wright (c...@daverandom.com) wrote:
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: > >> >> ...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. 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. At this point I’m a bit confused about what the scope of the discussion is. Are we talking about creating more semantic aliases for $_GET and $_POST, or integrating support to retrieve data from $_POST based on the HTTP method, or a little bit of both? — Mike Dugan m...@mjdugan.com
