> On Nov 7, 2014, at 12:16 AM, Sherif Ramadan <theanomaly...@gmail.com> wrote: > > On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds <a...@ajf.me > <mailto:a...@ajf.me>> wrote: > >> >>> On 7 Nov 2014, at 00:53, Stas Malyshev <smalys...@sugarcrm.com> wrote: >>> >>> Hi! >>> >>>> Again, I think you're oversimplifying the problem. For one, you don't >> know >>>> that the payload is JSON unless you check the Content-type header >> yourself, >>>> and you really shouldn't have to since PHP could easily do this for you. >>> >>> Sure, PHP could easily do this, or any other one specific use case for >>> you. What it can't do, however, is to do all 1000 use cases that modern >>> REST application presents, automatically for you. What if you use XML >>> and not JSON? What if you use both and determine which one it is by >>> request URL suffix being .xml or .json? What if it instead is switched >>> by query parameter? What if also it can be compressed, encrypted and >>> wrapped in some MIME multipart message? Having all these complications >>> handled in the core of PHP would be extremely hard, not because each of >>> them is hard, but because there can be so many of them. And you'd run a >>> big change of PHP still not matching your specific case exactly, or >>> being behind times, because core can not evolve as quickly as userland >>> does. That's why it's better done in extensions or user space - unless >>> you can identify a case which covers a huge proportion of all cases - >>> just like forms are for POST. For generic REST, I'm not sure there's >>> such case, except for very generic API giving access to the basic >>> request, its fields and supporting basic URL/MIME parsing. >> >> Even just parsing JSON isn’t as simple as it sounds. There are several >> things users might like to configure, several ways to parse JSON (objects >> vs. arrays, big numbers as floats or strings, etc.), while for form-data >> there’s only one way. >> > > Well, in this case it will be parsed as an array since $_POST is naturally > parsed as an array. Also, since $_POST/$_GET are typically always processed > as strings it would only make sense to use big numbers as strings in the > JSON parsing as well. I don't think this is the big issue. The bigger issue > is do users typically find the population of $_POST more useful than just > reading the input stream themselves and handling the JSON payload on their > own.
Sherif - I’m just going to be straight here. I haven’t seen support for your proposal at all in this thread. You continue to try and make this case, but it continues to be shot down with absolutely valid issues, and your only responsive action is to argue back. Why aren’t you considering alternatives? Everything - and I do mean everything - that you want is available in pecl/http, and there’s already an RFC to get it into core. Why can’t you get behind that and either support it, or move to propose an alternative that is supportable by at least someone. Your current proposal is not supported by anyone in this thread, and you still can’t see that. I admire and appreciate your efforts in making PHP better, but it’s time to go back to the drawing board on this proposal. Everyone is against it, and I feel this thread’s patience is running thin. > > >> >> -- >> Andrea Faulds >> http://ajf.me/ <http://ajf.me/>
