Re: RFC: Server-Side Request and Response Objects (v2)
| From: | Paul M. Jones | Date: | Fri, 14 Feb 2020 15:47:25 +0000 |
| Subject: | Re: RFC: Server-Side Request and Response Objects (v2) | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108581@lists.php.net to get a copy of this message | ||
Hi Côme & Niklas,
> On Feb 13, 2020, at 04:52, Côme Chilliet <come.chilliet@fusiondirectory.org> wrote:
>
> Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit :
>
>> Naming
>>
>> I think we shouldn't take over the naming of the super globals, e.g.
>> $_GET really contains the query parameters and has nothing to do with
>> GET or POST, so $request->getQueryParameter(...) would be a better
>> name.
>
> I think this remark is really on point.
> GET and POST are HTTP methods and not ways of passing data. You can have query parameters on
> any request, and you can have POST data with a lot of other HTTP methods, as is commonly used in
> REST APIs.
Your comments on naming are well-made.
While working on the implementation, we tried out $query instead of $get, on exactly the premise
that you state: i.e., that
$_GET holds the query parameters, and has nothing to do with
the GET method. But in the end, we settled on mapping more directly from $_GET =>
$get, and $_POST => $post.
Having said that, we are willing to revisit that naming decision if there's support for doing
so. Perhaps:
- rename $get to $query, populating it from $globals['_GET'], on the basis
stated above
- rename $post to $input, populating it from $globals['_POST'], on the basis
that it typically relates to the parsed form of php://input
Your (and/or anyone else's) thoughts on that?
--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php