Re: RFC: Server-Side Request and Response Objects (v2)
| From: | Paul M. Jones | Date: | Fri, 14 Feb 2020 22:12:24 +0000 |
| Subject: | Re: RFC: Server-Side Request and Response Objects (v2) | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108589@lists.php.net to get a copy of this message | ||
Hi all,
> On Feb 14, 2020, at 10:47, Benjamin Morel <benjamin.morel@gmail.com> wrote:
>
>>
>> What about $query and $body? That would be closer to the terminology
>> used in HTTP RFCs.
>
>
> The problem is that $body is typically used to get the raw message body as
> a string or stream.
>
> I was thinking more something along the lines of $bodyParams, which is more
> verbose but leaves no ambiguity: *$queryParams* and *$bodyParams*.
I get the desire to disambiguate. But as an added consideration, there's a desire for
consistency; when adding a -Params suffix to those names, it might then make sense to have
$serverParams, $cookieParams, etc.
Looking at it that way, I don't think a -Params suffix is necessary. I would think $query would
be enough.
As for the other name, the one for the $_POST equivalent, $body doesn't seem quite right to me;
it seems a little close to $content. I've also been thinking about $values, $params,
$parsedContent, $contentValues, $bodyValues, $contentArray, and other variations with and without
prefixes and suffixes, but $input is the one that feels like the least-terrible alternative to $post
for me, esp. given the connection to php://input.
--
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