That does not make any sense; applications could accept XML, CSV or whatever 
else just as well.

The original proposal is not very useful. $_GET contains parsed query string 
info, $_POST contains parsed HTTP request body information if the media type is 
application/x-www-urlencoded or multipart/form-data. Deserializing that makes 
sense as the rules for it are in the HTTP spec.

$_PUT/$_BODY/$_DATA would then have to contain the raw body contents, at least 
if the media type isn't one of the above, for consistency. That'd saves the 
file_get_contents() call, and given how a request handler uses at most once, 
I'm not sure such a change is worth it.

David


On 17 Aug 2014, at 04:18, Thomas Bley <ma...@thomasbley.de> wrote:

> Since we get JSON data, I would also consider $_JSON.
> 
> Regards
> Thomas
> 
> 
> Park Framework wrote on 17.08.2014 01:47:
> 
>> Variable $_PUT is already a popular name.
>> Many for yourself already so it was called, at the bottom link.
>> http://stackoverflow.com/search?q=PHP+%24_PUT
>> 
>> But I like the name $_DATA - it is universal for any request method.
>> For frontend developers, this name is very clear:
>> $.ajax({
>>   type: "PUT",
>>   contentType: "application/json",
>>   data: {"name": "value"}
>> });
>> 
>> Except multipart form data, needed and native support for application/json.
>> 
>> In many languages (Java, Python, ASP), it has long been there.
>> It is a pity that the PHP in 2014, it has not yet implemented.
>> 
>> 
>> 
>> 2014-08-17 2:14 GMT+03:00 Chris Wright <c...@daverandom.com>:
>> 
>>> On 16 August 2014 23:41, Park Framework <park.framew...@gmail.com> wrote:
>>>> This is necessary for convenient use RESTful API.
>>>> 
>>>> file_get_contents('php://input')  - Very inconvenient
>>>> 
>>>> I would like to finally get native support for PHP, preferably version
>>> 5.6
>>> 
>>> The window for getting new features into 5.6 has passed, quite a long time
>>> ago.
>>> 
>>> Also, there is no $_PUT superglobal (and personally I do not think
>>> there should be one), and it would not make sense to put this data
>>> into $_POST (or any existing superglobal). Please explain the API you
>>> envisage to get this working.
>>> 
>> 
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Reply via email to