Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76592
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGAGxbYjc7MAnKQBNB6hb6StsWaRMshxUZieebmoYXHeNmFGyw@mail.gmail.com>
References: <CAPRqa+G7_quRQ-NR04DChPEZeevuRBHX_1GbOCO+N4VXnzrCTw@mail.gmail.com>
	<CAGAGxbYjc7MAnKQBNB6hb6StsWaRMshxUZieebmoYXHeNmFGyw@mail.gmail.com>
Date: Sun, 17 Aug 2014 02:47:51 +0300
Message-ID: <CAPRqa+Hu4dqCs3X7O+Kh3A15eRQG-savV+2i-R=A3VGp-t6fxA@mail.gmail.com>
To: Chris Wright <cw@daverandom.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0158bab41537fe0500c7c471
Subject: Re: [PHP-DEV] Native support - PUT request, multipart form data
From: park.framework@gmail.com (Park Framework)

--089e0158bab41537fe0500c7c471
Content-Type: text/plain; charset=UTF-8

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>:

> On 16 August 2014 23:41, 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
>
> 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.
>

--089e0158bab41537fe0500c7c471--