> there's really nothing missing from PHP today to enable successful & easy implementation of RESTful interfaces.
Zeev, I could not create a REST interface that accepted "multipart form data" in uploading a file and form data in one PUT request. This is a valid part of a RESTful interface, yet PHP does not provide parsed data and file data for PUT like it does for POST (in the form of $_FILES and $_POST). The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. I had written one, but would rather rely on the more-well tested parser which exists in PHP itself for POST. (A side-note: in my case it was deemed less risky to employ a load-balancer hack instead). Having the ability to access the data provided in $_POST for other methods is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc). Dave. On 14 October 2014 14:56, Zeev Suraski <z...@zend.com> wrote: > > Personally, I like the idea of using more appropriately named aliases, > > particularly if they're roughly the same number of characters. However, > > we > > would need to allow at least several years for people to adopt the new > > globals before deprecating $_GET and $_POST. Ultimately, they will > either > > need to be deprecated or the $_PUT and $_DELETE aliases will need to be > > added, otherwise the issue I raised would remain unresolved. > > Kris, > > Don't get this the wrong way, but $_GET and $_POST are not going to be > deprecated. > > Whether or not we need $_PUT or $_DELETE is a separate, independent > question > from the axiom that $_GET and $_POST are here to stay. Personally, I don't > think they make sense as Rasmus pointed out that $_GET and $_POST were > never > about HTTP methods but form methods, and there's really nothing missing > from > PHP today to enable successful & easy implementation of RESTful interfaces. > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
