Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78058
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <543D47C1.9050009@lerdorf.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>
	<543D47C1.9050009@lerdorf.com>
Date: Tue, 14 Oct 2014 22:47:34 +0300
Message-ID: <CAPhkiZxorX5KEtwa0CXfZWKR3hxQb5OgrfG1PzUOaERCaEEtfQ@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Andrea Faulds <ajf@ajf.me>, Kristopher <kristopherwilson@gmail.com>, 
	Kris Craig <kris.craig@gmail.com>, PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] New globals for PUT and DELETE
From: narf@devilix.net (Andrey Andreev)

Hi,

On Tue, Oct 14, 2014 at 6:56 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 10/14/2014 06:29 AM, Andrea Faulds 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 s=
ense, but isn=E2=80=99t 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?
>
> It makes no sense to me to make $_BODY an alias for $_POST. $_POST
> implies the default body encoding that a broswer performs on a POST
> request. Making an alias called $_BODY that doesn't contain the body of
> a request unless it is "POST"-encoded would be super confusing.
>
> I think the pedantry level around this is rather high. Nobody is
> actually confused about $_GET and $_POST and how and when to use them.
> Adding vague aliases adds confusion to something that had no confusion
> before.
>
> -Rasmus

I agree ... in a strange way.

The pedantry level is indeed high, but being a pedant myself, I have
to point that *confusion* is the wrong word. It's *misconception* and
it is very widespread.

The vast majority of users, those who don't know PHP _that_ well and
those who aren't familiar with the HTTP specification, do make a
direct relation between HTTP methods/verbs and the $_GET, $_POST
superglobals. The OP's proposition for $_PUT and $_DELETE here is
quite probably driven by the same perceived relation.

Most users see $_GET and then they see a GET/foo/bar HTTP/1.x request
and they think that's what it's all about. I haven't once heard from a
PHP developer _in person_ to refer to $_GET as query parameters. To
them, it's "GET parameters".
They know that there's nothing in $_POST unless they submit their form
with method=3D"post" and they believe that $_POST relates to POST
requests. In this case that's a more correct assumption, but still
missing the detail that Content-Type is important.

As a self-taught developer, I've gone through this myself. PHP had for
so long allowed me to build web applications without knowing how they
work at the low level and that was really, really great, but it also
tricked me into making the wrong assumptions.


All of the above aside however, I also don't think that aliasing to
$_QUERY and $_BODY or $_FORM would provide any real-world benefit.
We'd be lucky if people learn to only use the new "aliases" in 10
years ... not worth it given that we've dealt with $_POST and $_GET
for 20 years.
Populating $_POST with parsed payloads from other types of requests is
also not practical because RESTful services rarely use the
form-urlencoded format. And also because it would be further spreading
misconception, of course.


To address the misnomers, it's important to document that $_GET and
$_POST don't really represent GET and POST requests.

To aid the development of RESTful services, new and more appropriate
APIs should be provided. And we have to admit that there's a need for
that in the first place ...

json_decode(file_get_contents('php://input')) will work for many
people, but as somebody else already mentioned: there are other, more
structured subsets of JSON ... HAL was already mentioned, JSON-Patch
is another. What about XML and DTDs? Other formats?

Don't get me wrong, php://input is an awesome low-level solution. But
because we don't have a high-level one, it's also kind of: "Here, have
this thing and deal with it, we don't care if you really can."
So, to reiterate on my previous reply to this thread, what I think we
really need is to be able to register parsers at runtime, much like we
do with autoloaders. For example:

    // Can't think of better function names right now ...
    request_content_type_register($contentType, Callable $parser)
    request_request_body(array &$assignParsedDataHere)

Of course ... input parsing should be done only once, so it's not
quite like with the spl_autoload queue, but I don't see an easier way
to deal with the problem.
Parsers for common formats such as application/json (depending on
available extensions) could be pre-registered, or not ... that's not
really important.

Cheers,
Andrey.