Re: RFC: Server-Side Request and Response Objects (v2)

Hi all, > On February 13, 2020 1:52 PM 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. > > I do not like the name getQueryParameter at first sight, but I do not like get() and post() for > getting values from $_GET and $_POST. > I would expect a method named post to actually post something, not just get a value. > > -- > Côme Chilliet > FusionDirectory - https://www.fusiondirectory.org > > -- I agree that this is indeed on point. Personally I would like $request->getQueryParameter() and $request->getBody() over $request->get() and $request->post(). In the former case you are asking for the parameters in the query string (query component of the URI) and the latter is to get the request body. These method names make it very clear what you're asking for. What kind of bothers me in general about this RFC is that... we are talking about Request and Response and these are standard HTTP components, yet the RFC is about providing wrappers for existing global PHP variables and functions. It does not try to model these components as they are in their standard, nor aim to do so. This is why I believe it's better to leave it to userland implementations. Besides the fact that they are widely adopted, they attempt to follow the specification they are providing. Regards, Ekin H. Bayar https://ekins.space https://heap.space