Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78010
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mjdugan.com from 209.85.216.43 cause and error)
Date: Tue, 14 Oct 2014 10:16:10 -0400
To: Chris Wright <cw@daverandom.com>, Kris Craig <kris.craig@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, Kristopher <kristopherwilson@gmail.com>, 
 PHP internals list <internals@lists.php.net>, Chris Wright
 <cw@daverandom.com>, Andrey Andreev <narf@devilix.net>
Message-ID: <etPan.543d302a.79e2a9e3.12d@Mikes-iMac.local>
In-Reply-To: <CAGAGxbbpJoL+bnVDvevioVafyk-NpqnTwHy5x3Bvh_sBU9pTkw@mail.gmail.com>
References: <CAKOpQSwS=Xck41sQQyEYGG8L3VHq+fRWjy0dDorbwZaVWMLCow@mail.gmail.com>
 <776669CE-9E8C-4069-9834-C7275CCA0EF4@ajf.me>
 <CAKOpQSwRtSU1LNmftyY1b09SONBCfwS-qiMK4gct6uFiW3CSjw@mail.gmail.com>
 <CAPhkiZwb13FmX+sQLx0Ki52KuwJ4HWTj-84UqcZq3GYPFL8Tnw@mail.gmail.com>
 <E8F7D721-767C-4E6E-B0BB-F0DEFEB308B2@ajf.me>
 <CAF9U7z_0cgwWFEoShU9rJhoOZttztcZk_NAqoXnSuAro-w3kew@mail.gmail.com>
 <8CB055D4-F164-4DF3-B019-684BAE7E016E@ajf.me>
 <etPan.543d27fe.2ae8944a.12d@Mikes-iMac.local>
 <CAKOpQSzU4mUEDRX25z8TCbtDD04rDBBmF439p_Q65g2jjDMcpw@mail.gmail.com>
 <CAGAGxbYkj2ZMo8Zx1w-NdE2dZfZPkenWrCOaZAfi0nMVT56jxg@mail.gmail.com>
 <CAKOpQSzykDwF1pngGA=pcew2TT4GiaC3cR6v1cza0kUqAzkj7Q@mail.gmail.com>
 <CAGAGxbbpJoL+bnVDvevioVafyk-NpqnTwHy5x3Bvh_sBU9pTkw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="543d302a_7545e146_12d"
Subject: Re: [PHP-DEV] New globals for PUT and DELETE
From: mike@mjdugan.com (Mike Dugan)

--543d302a_7545e146_12d
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


--=C2=A0
Mike Dugan
mike=40mjdugan.com

On October 14, 2014 at 10:08:56 AM, Chris Wright (cw=40daverandom.com) wr=
ote:

On 14 October 2014 14:57, Kris Craig <kris.craig=40gmail.com> wrote:=C2=A0=

> On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright <cw=40daverandom.com> wro=
te:=C2=A0
>=C2=A0
>>=C2=A0
>> ...but is also the wrong solution. It's not scalable,=C2=A0
>=C2=A0
>=C2=A0
> How is it not scalable, exactly=3F It's just a couple aliases.=C2=A0

Because in a few years when the =46OO request method has become=C2=A0
commonplace we will get requests to add support for =24=5F=46OO, and then=
=C2=A0
=24=5FBAR, and the =24=5FCHEESE... where does it end=3F=C2=A0

>=C2=A0
>> and the only=C2=A0
>> sensible way to implement them would be as aliases of =24=5FPOST, beca=
use=C2=A0
>> they would contain the same data. How does this fundamentally differ=C2=
=A0
>> from =24=5FBODY (or whatever)=3F=C2=A0
>>=C2=A0
>=C2=A0
> It's not supposed to functionally differ. It's supposed to create some=C2=
=A0
> better consistency and make it easier for devs to differentiate between=
=C2=A0
> different REST methods when retrieving data. If REQUEST=5FMETHOD is PUT=
,=C2=A0
> then I can set the parsed params to the value of =24=5FPUT. The aliases=
 match=C2=A0
> the methods used, making the code that much more readable and scalable.=
=C2=A0

To be brutally honest I see this as a discussion of highly=C2=A0
questionable merit anyway, due to the fact that in the overwhelming=C2=A0=

majority of cases where the request method is not POST the entity body=C2=
=A0
will not represent HTML form data - browsers don't make requests of=C2=A0=

these methods with the involvement of client-side scripting at the=C2=A0
moment (or in the foreseeable future), the content type of the request=C2=
=A0
body is *highly* unlikely to be something PHP would even attempt to=C2=A0=

decode.=C2=A0

Sorry.=C2=A0
At this point I=E2=80=99m a bit confused about what the scope of the disc=
ussion is. Are we talking about creating more semantic aliases for =24=5F=
GET and =24=5FPOST, or integrating support to retrieve data from =24=5FPO=
ST based on the HTTP method, or a little bit of both=3F

=E2=80=94

Mike Dugan

mike=40mjdugan.com



--543d302a_7545e146_12d--