[RFC] $request->body->get

[ro0NL]

Description

Hi,

I'd like to propose $request->body->get() (an InputBag) to provide uniform access to a structured request body payload, regardless of content-type.

$request->request always looked weird to me, and is bound to $_POST, thus application/x-form-urlencoded:

https://github.com/symfony/symfony/blob/ed1b002bacf60b003a2ffcdd07e78f1d1bf0773f/src/Symfony/Component/HttpFoundation/Request.php#L293

Then for application/json one needs toArray(): https://github.com/symfony/symfony/blob/ed1b002bacf60b003a2ffcdd07e78f1d1bf0773f/src/Symfony/Component/HttpFoundation/Request.php#L1502

Example

$request->body = new InputBag($_POST ?: $request->toArray());

[ro0NL]

this is not about adding support for XML, YAML, etc. though i'd fundamentally agree it should be possible to add later

ideally the parsing happens in a lazy manner, thus a LazyInputBag or so

[rvanlaak]

I also remember this being quite confusing when I started working with Symfony back then, especially as the variable itself most often is named $request already.

[kbond]

@symfony/mergers any thoughts on this. I really like the idea. I think it's common to want to get the array of data from a request and not care if it's a form request or json.

My only hesitation is the name body - it doesn't necessarily imply this will be a structured array.

One idea @ro0NL had is to perhaps deprecate Request::getContent() in favour of Request::getRawBody(). I've often looked for a Request::getBody() to get the raw body before finding it's actually Request::getContent(). Additionally, maybe Request::$request could be deprecated in favour of Request::$form?

[welcoMattic]

I would love to clarify the $request->request thing, it was confusing to me when I started to code with Symfony too :+1:

[chalasr]

I agree as well that it’s worth renaming.

[OskarStark]

I agree as well that it’s worth renaming.

Me too 👍

[maxbeckers]

I like the idea of renaming $request->request. But why form? This sounds to me as well confusing, because its maybe formdata, but not the form. I'd prefer to name it body or maybe data, because it's the posted data of the request.

[kbond]

This issue has sort of morphed into three things.

1. A new property ($body) that represents either the $_POST data or json request body (the initial part of this issue).
2. Renaming the $request property (which is a wrapper for $_POST) to something else (#47938). I chose $form because this is what $_POST represents, the form data. I'm not completely convinced that $form is the best term (it's better than $request IMO) - maybe $post would be better?
3. Renaming Request::getContent() to getRawBody().

[maxbeckers]

Yes, you are absolutely right. There are exactly these 3 topics here in this issue. Thanks for clarifying. And yes you are right, from the naming point of view body doesn't really fit well then either. $post(Data) also sounds a bit strange to me, but yeah, maybe it's best to name it that way. Better than request it is in any case.

[chalasr]

I'm not completely convinced that $form is the best term (it's better than $request IMO) - maybe $post would be better?

My preference goes for body, I think it's the the most consistent with PHP and HTTP terms:

[kbond]

My preference goes for body, I think it's the the most consistent with PHP and HTTP terms:

Now, do you think $body should be new InputBag($_POST ?: $this->toArray()) as initially described by this issue or a straight up rename of $request?

[GromNaN]

Now, do you think $body should be new InputBag($_POST ?: $this->toArray()) as initially described by this issue or a straight up rename of $request?

I would love if $request->body could be populated equally from x-www-form-urlencoded or application/json requests. Adding a new property is the right opportunity to do so.

For backward-compatibility, we cannot do the same for $request->request. Thus, they needs to be distinct objects.

[ro0NL]

i understand if this is too disruptive

also i realized for us the better path is to deserialize requests into dedicated (message) DTOs, and dispatch from there

[wouterj]

I think we should keep this issue open, or at least close as completed.

We have an open PR about this (#47938) that we should continue, we can do this in a non disruptive way.