On Thu, Nov 6, 2014 at 7:53 PM, 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. > Sure, you make a good point, here. The handling of a RESTful request in user land may vary based on individual requirements. However, I'm not proposing that PHP does the actual handling of the request, just that it makes user land code more readily equipped to enable the user to do that handling. In the same way that it does for POST. This creates some more consistency and makes the typical request slightly more ubiquitous since users are already used to $_POST and $_FILES when handling incoming request input. For this to be possible in a more generic sense this would mean that PHP only relies on the Content-encoding and Content-type headers to determine how to decode the payload and parse its contents into super global variables such as $_POST and $_FILES. This is currently what PHP's SAPI implementation already does. The changes required to make this available to a wider array of use cases such as JSON vs form-url-encoded encoding, for example, are not so complicated. After that it's up to the user to decide what to do with the data in terms of handling the request. Content-encoding will most likely be handled at a higher level than PHP as it is in most cases today (deflate, etc... handled by the webserver) If the Content-type is applicatoin/json, for example, instead of the normal application/x-www-form-urlencoded, PHP would simply parse the enclosed entity body as JSON rather than urldecode it. If the Content-type header is set to a multipart/form-data MIME, then PHP does what it typically does with POST, but allows PUT to work the same. You would still stick to the same boundary requirements of the multipart/form-data MIME in the same way that post does, so encoding can't vary. If the Content-type header is application/binary, for example, we can simply make the file available in $_FILES or just leave it in the input stream (probably best to just leave it in that case). If PHP fails to find these headers properly set it would fall back to the same thing it does today (leave it up to the input stream consumer to parse the entity body). I suppose if we also exposed the request headers to the user we could make it more effective for them to make their own decisions about handling other edge cases differently based on those request headers (such as in the case of non-standard headers X-*, for example). Here, I'm just proposing that PHP take on the addition of PUT handling in a similar fashion that it does for POST, but only in the even that the request comes in as a mulitpart/form-data MIME type. This could make a lot of people's lives a little easier in dealing with PUT, but it's clearly not a solution to for abstracting away the entire logic of handling RESTful requests. So I can definitely see your hesitation to include this in core. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ >
