Why does HTTP's PUT method mandate a 201 Created/204 No Content split?
HTTP includes this in its definition of the PUT method:
If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.
The standard — pretty strongly — mandates that the server MUST return a 201 if the target resource is created. But why? Is there some good reason to inform the client that the PUT was a creation, as opposed to a modification?
From my perspective as a server writer, this is an onerous requirement: the storage service I'm writing to supports upserting, but doesn't actually give me any indication of whether the upsert was an update or an insert, unfortunately. I can query beforehand, but the underlying service also doesn't give me atomicity around that query and the subsequent upsert, and that adds an extra round-trip to the underlying service, all just to determine what status code to send.
Is there a good reason why I shouldn't just ignore the spec here, and just always return one of 201 Created or 204 No Content regardless of whether it was semantically a create?
上一篇: 我可以使用哪些“clearfix”方法？