On Oct 14, 2014, at 8:09 AM, Kris Craig <kris.cr...@gmail.com> wrote:

> On Tue, Oct 14, 2014 at 5:54 AM, Andrea Faulds <a...@ajf.me> wrote:
> 
>> 
>> On 14 Oct 2014, at 13:47, Kris Craig <kris.cr...@gmail.com> wrote:
>> 
>>> Hey guys,
>>> 
>>> Does anybody know why we have $_GET and $_POST, but not $_PUT and
>>> $_DELETE?  As far as I can tell, the only way to get these out currently
>> is
>>> to parse their values by reading the incoming stream directly.
>>> 
>>> Is there a reason why we don't want this or is it just that nobody has
>>> actually written it yet?
>> 
>> $_GET and $_POST are really misnomers. $_GET is query string parameters,
>> $_POST is request body data.
>> 
>> We should just put the request bodies for all requests, not just POST,
>> into $_POST.
>> 
> The problem with that approach though is that it would not be RESTful.  I'm
> developing a REST API (with the goal of 100% REST compliance) and having
> PUT/DELETE variables mixed in with $_POST would not only be
> counter-intuitive, but it would just present a new roadblock.
> Incorporating GET in there, as well, would make things even worse.
> 
> Basically, if we have $_GET and $_POST, then we should also have $_PUT and
> $_DELETE.  Either that, or they should all be tossed.  There's no reason
> why $_PUT and $_DELETE should not also exist.

Putting everything into $_POST isn’t a question of being RESTful or not. REST 
in a
Web application happens at the HTTP protocol level and not the PHP level.

That said, it would be confusing to place the request body for all requests 
into $_POST.
You also have to consider PATCH and the potential body for other HTTP methods. 
The
easiest way to get the body of any HTTP request is to use the input stream:

$requestBody = file_get_contents('php://input');

I suppose we could make a super global that returns that for us, but it’s just 
as easy to
use the above. Additionally, you might not want to put the full body of the 
request into
memory like that. You might rather read the stream only a few bytes at a time.

-Ben



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to