Re: Parsing PUT data

Thanks Daniel. My thoughts on your response: > Where does it stop? This is the problem I see with all the requests to support for PUT > similarly to POST. Right here with PUT. Providing a RESTful interface is hugely common and $_PUT is the only one missing to complete REST. PUT is the glaringly obvious one missing. > You could easily write a parser in userland to accomplish the same thing. I did originally. But it became obvious that (a) it's a common problem; (b) being non-trivial, it would a require very wide set of test cases to ensure it won't break in some random edge case; and (c) the functionality already exists for POST. Other languages (Ruby, for example) make REST very easy. Multipart support for PUT was literally the only issue I personally encountered when writing a public REST API in PHP. Dave. On 24/09/2013, at 7:59, Daniel Lowrey <rdlowrey@gmail.com> wrote: > > In short, in order to provide a proper REST service that supports multipart > > form data, we need someway to parse data sent via PUT (data is available > > via php://input, but it needs to be parsed). > > Multipart entity parsing is fairly straightforward. You could easily write a parser in userland > to accomplish the same thing. Unless you're doing a very high volume of CRUD via PUT the > performance hit of doing this in userland should be negligible. > > That said, I think exposing a function to do this could be a useful addition, and since PHP > already has code to parse these entities for POST requests it shouldn't be too much work to > expose that via something like a new mime_multipart_parse() function. It's not really a > priority for me, but you can probably find someone to work on this for you if you're not a C > person. > > The bigger issue here is that the superglobals are a leaky abstraction. Any HTTP request method > is allowed to have an entity body, so should we also create $_PATCH and $_PUT and $_ZANZIBAR to > handle less-frequently used request methods? Where does it stop? This is the problem I see with all > the requests to support for PUT similarly to POST. PHP web SAPIs support 95% of the HTTP use-cases > people have, but the abstractions break down after that and continuously bolting on support for > individual scenarios beyond that would be a mistake IMO.