On Oct 14, 2014, at 8:42 AM, Kris Craig <kris.cr...@gmail.com> wrote:
> Removing or renaming $_GET and $_POST would also create confusion and
> almost certainly cause widespread BC breakage on a pretty massive scale.
> And there's really no gain to offset that. So that just leaves us with
> either continuing to have two REST methods but not the others or add a
> $_PUT and a $_DELETE, even if they just alias to php://input again.
There is no standard way to deal with the data in $_PUT and $_DELETE. In fact,
DELETE rarely, if ever, contains a request body. RFC 7231 (section 4.3.5) says
this about payloads within DELETE requests:
A payload within a DELETE request message has no defined semantics;
sending a payload body on a DELETE request might cause some existing
implementations to reject the request.
There’s no standard way to deal with the data in $_POST, either, except that
HTML
forms send POST data by default as application/x-www-form-urlencoded, making it
easy for PHP to parse. When building RESTful APIs, that content type is rarely
used in favor of using JSON or XML content types, so even there the $_POST
super global in PHP is useless. You must still use php://input to get the
request
body for those POST requests.
While it might make sense to also include $_PUT, $_DELETE, $_PATCH, etc.,
we would also need to build in parsers for a variety of content types, and I
don’t
think this is the job of the PHP engine to look at the content type on every
request
and attempt to parse it in the way the developer expects it to be parsed. That’s
much better left up to the developer, extensions, and libraries.
Ben
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
