Re: New globals for PUT and DELETE
| From: | Kris Craig | Date: | Tue, 14 Oct 2014 13:57:44 +0000 |
| Subject: | Re: New globals for PUT and DELETE | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-78003@lists.php.net to get a copy of this message | ||
On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright <cw@daverandom.com> wrote:
> On 14 October 2014 14:46, Kris Craig <kris.craig@gmail.com> wrote:
> > On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan <mike@mjdugan.com> wrote:
> >
> >>
> >> On October 14, 2014 at 9:31:15 AM, Andrea Faulds (ajf@ajf.me) wrote:
> >>
> >>
> >> On 14 Oct 2014, at 14:27, Kristopher <kristopherwilson@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
> >>
> >> mike@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.
> 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.
--Kris