> On 6 Nov 2014, at 01:29, Sherif Ramadan <theanomaly...@gmail.com> wrote:
>
> So you're actually describing two semi-different problems here. One is that
> PHP doesn't actually inform you of the HTTP request VERB strictly through the
> naming of the super global variables $_POST and $_GET. However, $_POST being
> populated, right now, in PHP, strictly means the request verb was POST and
> that the content-type header received was multipart form data. Which means
> that sending something like a JSON payload (Content-type application/x-json
> or whatever) in the body of a POST request still doesn't populate the $_POST
> super global variable even though the HTTP request VERB was indeed POST.
That’s not actually my complaint. The thing is that, until now, you could
assume what was in $_POST was from a POST request. To allow data from PUT and
DELETE requests to go there by default is probably not a good idea, because
POST has quite a different meaning from PUT and DELETE.
> The other problem is that the semantics of REST itself are quite different
> from how PHP currently deals with the request data. In that PHP only cares
> about form data. However, this is quite antiquated with todays' modern use of
> HTTP growing in API-specific functionality. For example, companies like
> Twitter and Tumblr, demonstrate a vast majority of their traffic currently
> coming in at the API-level where things are usually handled in a RESTful
> manner. So for the PHP power houses today, PHP doesn't quite lend itself well
> to dealing with these problems first-hand. Instead we have to hack our way
> around them in userland, which can be more error-prone and less obvious.
Er… I wouldn’t say that PHP really handles REST APIs badly, or that the
userland approach is error-prone or less obvious. Using JSON isn’t difficult,
you just do this:
$data = json_decode(file_get_contents(‘php://input')) or die();
This isn’t a hack. It’s a straightforward and obvious way to do this.
> While that solution solves one specific problem (dealing with multipart form
> data of request types other than POST), it doesn't quite tackle some of the
> broader issues of dealing with incoming HTTP request in PHP that I would like
> to tackle.
Yes, I’m aware it doesn’t. I don’t think that the PUT/DELETE issue really
justifies your RFC. I don’t think there are any other problems which do,
either. There are better ways to solve them.
> I also think you're diminishing scope of this problem and the number of
> people affected by it. You not only have to think of the number of
> programmers dealing with the code, but the number of end-users indirectly
> affected by the problem as well. PHP is primarily a web-oriented language,
> and I think as such it should deal with these kinds of issues more readily.
> If you take a good look at the number of web-based APIs out there and how
> certain PHP client libraries try to deal with these kinds of problems the
> solutions are sometimes very poorly implemented or just outright wrong.
Your solution is to put even more stuff in userland so web developers can
produce even less functional applications which have buggy request parsing. I
don’t think that really helps anyone.
> We solved password hashing dilemmas with password_hash for a similar reason
> in PHP. In that people were just doing it wrong and didn't know any better.
> So I think making a more robust, and simpler interface to deal with these
> kinds of issues will encourage people to get it right in the future.
Sure, a nicer response/request interface, like the PSR proposals, would be
great. Your mechanism for parsing raw request data does not solve this problem,
in fact I suspect it would make it worse. Aside from that, it’d also severely
hurt performance.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
