Hacker News Reader

Comment by _greim_ | Hacker News Reader

My understanding is that "PUT" means "make it so that the contents of this request body live at this URL". Meanwhile classic HTML forms only send lists of name/value pairs. So it would have been saying "make it so that this list of name/value pairs lives at this URL" which isn't very useful and would likely have led to widespread creative abuse and corruption of the meaning of "PUT".

Likewise, it doesn't make much sense to send a request body with a DELETE, regardless of what it contains. Not forbidden, but not really useful either.

View on HN

The server can do whatever processing it likes to a PUT's request body. If you upload a PNG it can convert it to a JPEG or an SVG or OCR it or invert the colors, etc. It's perfectly valid to turn application/x-www-form-urlencoded into something else.

Converting "image/png" to "image/jpeg" is easy given a knowledge of those formats, but how do you convert "application/x-www-form-urlencoded" to "image/jpeg" or "text/html" or anything else? The only thing you can do is invent your own arbitrary convention, which begins to stray pretty far from the design and intent of PUT.

That would depend on what kind of service you're implementing.

"HTTP/1.1 does not define how a PUT method affects the state of an origin server."

I don't think it was ever the design or intent of PUT to store the exact representation that you gave it, and I would be surprised to see evidence otherwise.

Conceptually it's no different from POSTing (or PUTting) application/json to produce a resource that will be represented as text/html. How do you convert JSON to HTML? Depends on the service.

The only real difference between PUT and POST is that PUT creates a resource at a defined location. There's no difference with regard to the mapping-from-request-representation-to-preferred-server-representation between PUT and the common use case of POST to create a new member of a collection where the collection URI is the target of the POST, the only difference is that with put, the target URI is the location that the resulting resource will be placed rather than the location it will be subordinate to.

Since this problem isn't a barrier to using POST to create resources, it shouldn't be for PUT, either.

Reply on news.ycombinator.com