Native support - PUT request, multipart form data

2014-08-17 12:22 GMT+03:00 Ferenc Kovacs tyra3l@gmail.com:

On Sun, Aug 17, 2014 at 12:41 AM, Park Framework <park.framework@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

feel free to create an rfc/implementation, I don't think it would be wise
to introduce it in 5.6.x(there is zero chance to have this in 5.6.0), but
our releaseprocess allows small self-contained features in a micro version,
so you can try targetting 5.6.next with the rfc but there is a chance that
some people will vote no who otherwise would support this in 5.next or 7.0.
I tend to agree that it would be better to move away from the method named
superglobals, but ofc. killing off $_GET/$_POST could only happen in a
major version.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

I have never written RFC, and I'm not a developer in C/C++.
Will correct if the RFC write the author of the patch.
Thank you.

Maybe, select the best API can community.
The main thing that it was not a reason for delaying.

2014-08-17 3:25 GMT+03:00 Andrea Faulds ajf@ajf.me:

Variable $_PUT is already a popular name.

$_POST isn’t really POST data nor is $_GET really GET data. We shouldn’t
continue this silly naming tradition given both existing names are
inaccurate.

We should have a query parameters array and a request body parameters
array or blob.

Andrea Faulds
http://ajf.me/

As a variant, not to create a new super global variables, can be
modified $_REQUEST to OOP style

class _REQUEST implements ArrayAccess // for backward compatibility
{
....
}

// get as array, from body request
$_REQUEST->body

// get all http request headers
$_REQUEST->headers

// get method request - POST, PUT...
$_REQUEST->method

// get Content-Type: multipart/form-data or application/json or ...
$_REQUEST->type

// get Content-Length request
$_REQUEST->length

It looks nice, but in practice it is more convenient to use an global
array - $_DATA or $_BODY or $_INPUT.

You can also do:

class _INPUT implements ArrayAccess
{

public function get($name, $default = null) {

if(isset($this->data[$name]) {

    return $this->data[$name];

 }
 else {
     return $default;
}

}

public function filter($name, $filter = FILTER_DEFAULT, $options = null) {

   return filter_var($this->data[$name], $filter, $options);

}
}

Examples:

$value = $_INPUT->get('varName1', 'myDefaultValue');
$email = $_INPUT->filter('varName2', FILTER_SANITIZE_EMAIL);

2014-08-17 3:25 GMT+03:00 Andrea Faulds ajf@ajf.me:

Variable $_PUT is already a popular name.

$_POST isn’t really POST data nor is $_GET really GET data. We shouldn’t continue this silly naming tradition given both existing names are inaccurate.

We should have a query parameters array and a request body parameters array or blob.

Andrea Faulds
http://ajf.me/

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

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 cw@daverandom.com:

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.