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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
