Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Use 200/201 on PATCH/PUT instead of 205

See original GitHub issue

Following on PR #620, I would like to suggest changing the i.m.o. inappropriate 205 response code on (succesful) PUT and PATCH requests to 201 and 200 respectively. I emphasize an excerpt from RFC 7231 to clarify my point.

The 205 (Reset Content) status code indicates that the server has fulfilled the request and desires that the user agent reset the ‘document view’, which caused the request to be sent, to its original state as received from the origin server. This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), enters or manipulates data in that space, causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action. Since the 205 status code implies that no additional content will be provided, a server MUST NOT generate a payload in a 205 response.

To me, this clearly indicates why 205 is inappropriate. The Solid architecture design document reads:

The server responds with … 205 if method is PUT or PATCH. When possible, the body of this response should respect the agent’s representation preferences.

This is part of Step 5: Return a representation, and thus clearly not in line with the no-payload directive of the 205 code. Moreover, since the server has no native document view for data entry, there is nothing to be ‘reset’.