Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77983
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSwRtSU1LNmftyY1b09SONBCfwS-qiMK4gct6uFiW3CSjw@mail.gmail.com>
References: <CAKOpQSwS=Xck41sQQyEYGG8L3VHq+fRWjy0dDorbwZaVWMLCow@mail.gmail.com>
	<776669CE-9E8C-4069-9834-C7275CCA0EF4@ajf.me>
	<CAKOpQSwRtSU1LNmftyY1b09SONBCfwS-qiMK4gct6uFiW3CSjw@mail.gmail.com>
Date: Tue, 14 Oct 2014 16:23:09 +0300
Message-ID: <CAPhkiZwb13FmX+sQLx0Ki52KuwJ4HWTj-84UqcZq3GYPFL8Tnw@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] New globals for PUT and DELETE
From: narf@devilix.net (Andrey Andreev)

On Tue, Oct 14, 2014 at 4:09 PM, Kris Craig <kris.craig@gmail.com> wrote:
> On Tue, Oct 14, 2014 at 5:54 AM, Andrea Faulds <ajf@ajf.me> wrote:
>
>>
>> On 14 Oct 2014, at 13:47, Kris Craig <kris.craig@gmail.com> wrote:
>>
>> > Hey guys,
>> >
>> > Does anybody know why we have $_GET and $_POST, but not $_PUT and
>> > $_DELETE?  As far as I can tell, the only way to get these out currently
>> is
>> > to parse their values by reading the incoming stream directly.
>> >
>> > Is there a reason why we don't want this or is it just that nobody has
>> > actually written it yet?
>>
>> $_GET and $_POST are really misnomers. $_GET is query string parameters,
>> $_POST is request body data.
>>
>> We should just put the request bodies for all requests, not just POST,
>> into $_POST.
>>
>> --
>> Andrea Faulds
>> http://ajf.me/
>>
>>
> The problem with that approach though is that it would not be RESTful.  I'm
> developing a REST API (with the goal of 100% REST compliance) and having
> PUT/DELETE variables mixed in with $_POST would not only be
> counter-intuitive, but it would just present a new roadblock.
> Incorporating GET in there, as well, would make things even worse.
>
> Basically, if we have $_GET and $_POST, then we should also have $_PUT and
> $_DELETE.  Either that, or they should all be tossed.  There's no reason
> why $_PUT and $_DELETE should not also exist.
>
> --Kris

This has nothing to do with REST.

$_GET doesn't even relate to GET requests, it's just query parameters.
Query parameters exist in all types of requests because they are part
of the URI.
$_POST (even if only parsed for POST requests) also represents just
the request body parsed from a very specific format.

There's no reason to have $_PUT, $_DELETE, etc. because they would
represent the same thing - php://input parsed from
application/x-www-form-urlencoded.

That being said, from a purely semantic prospective, both $_GET and
$_POST should be tossed - yes. In reality, you can't do that because
virtually all PHP applications use them. But this is no reason to add
even more global vars with such misleading ... meanings.

What would be nice is to be able to register userland parsers into a
"request body parser" of some kind, so that you can have automatic
parsing depending on the Content-Type header.

Cheers,
Andrey.