On Tue, Oct 14, 2014 at 6:09 AM, Ben Ramsey <b...@benramsey.com> wrote:
> On Oct 14, 2014, at 7:47 AM, Kris Craig <kris.cr...@gmail.com> wrote: > > > Hey guys, > > > > Does anybody know why we have $_GET and $_POST, but not $_PUT and > > $_DELETE? As far as I can tell, the only way to get these out currently > is > > to parse their values by reading the incoming stream directly. > > > > Is there a reason why we don't want this or is it just that nobody has > > actually written it yet? > > > > —Kris > > This is due to the history of HTML forms sending POST requests with the > Content-Type application/x-www-form-urlencoded. That is, all the fields are > key/value pairs and may be easily converted into a PHP array. If you use > POST with application/json, nothing appears in $_POST, for example. > > In practice, we could support $_PUT and $_DELETE for requests that use > application/x-www-form-urlencoded, but most folks implementing PUT and > DELETE do not use application/x-www-form-urlencoded for these requests. > > I would venture to say that most people implementing PUT requests accept > application/json and most DELETE requests have no body at all. So, $_PUT > and $_DELETE superglobals wouldn’t make sense. > > -Ben > > I'm not following your logic, Ben. Just because there are a lot of people out there who don't understand REST, doesn't mean we shouldn't add support for the other methods. Besides, if anyone wants to develop a truly RESTful API in PHP-- which a lot of devs are doing every day-- not giving them $_PUT and $_DELETE is what wouldn't make any sense. I'm writing an API now and the lack of those two globals has proven to be a real pain in the ass. The Content-Type argument really isn't an issue since the API developer should be setting the right headers for the request method, anyway. I don't see any gain in not making those globals available. All it does is present both inconvenience and inconsistency for any REST-based project. --Kris
