On Tue, Oct 14, 2014 at 6:25 AM, Andrea Faulds <a...@ajf.me> wrote: > > On 14 Oct 2014, at 14:23, Andrey Andreev <n...@devilix.net> wrote: > > > That being said, from a purely semantic prospective, both $_GET and > > $_POST should be tossed - yes. In reality, you can't do that because > > virtually all PHP applications use them. But this is no reason to add > > even more global vars with such misleading ... meanings. > > Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET > and $_POST then. Because they’re aliases (by-reference superglobals), > there’s no additional memory consumption, but we finally have saner names. > -- > Andrea Faulds > http://ajf.me/ > > I don't think that would be a good idea, either. They require more typing and it'd probably be a lot easier for devs to remember which one means GET and which one means POST.
The fact that $_PUT and $_DELETE aren't necessary because we can use other approaches to get that data is irrelevant. Having globals for two REST methods but not the other two is very counter-intuitive from a dev standpoint. We just recently discussed how PHP tends to have duplicate ways of doing something in order to make it as easy as possible. I believe this is one of those times. It would make it a lot easier for devs, particularly the ones less experienced with REST, to create APIs that actually use the correct methods without running into the confusion over why there's a $_GET and a $_POST but not a $_PUT or a $_DELETE. PHP is supposed to be KISS, right? Well, the current reliance on php://input for two methods but not the other two invites confusion. That makes it less-than simple, I believe. 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. --Kris
