Hacker News Reader

Comment by bct | Hacker News Reader

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.

View on HN

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