3 ms·

> Which is wrong. Response codes say nothing about the body. Actually, that's not correct. A response code can say a fair bit about the body, especially about

> Which is wrong. Response codes say nothing about the body. Actually, that's not correct. A response code can say a fair bit about the body, especially about whether it exists or not, but in some cases also the nature of the body. For example, a 203 says that the body of this request is not the same as the body sent by the origin server. A 204 tells the user agent that there's no body. 400s and 500s SHOULD have a body which includes an explanation of the error.

quesera 4y ago
> 400s and 500s SHOULD have a body I agree about 4xx bodies, generally. They indicate that the request was malformed or unsuccessful in some way. The requester can fix this problem. I think a 5xx should always represent an error on the server side that the requester cannot fix. It is always a bug or system failure to return a 5xx, which should be fixed by the API operator. Therefore no details are required or desirable to return to the requester.
- d1sxeyes 4y ago
  That may be your opinion, but the spec is clear: 6.6 [...] Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation[...].
  - dragonwriter 4y ago
    SHOULD is not MUST [0], and “The user can do nothing about the problem and is likely to experience negative utility from any attempt to provide more detail than what the status code provides” is arguably a valid reason not to send a body with 5xx status responses. [0] https://www.rfc-editor.org/rfc/rfc2119.html https://www.rfc-editor.org/rfc/rfc2119.html
    - d1sxeyes 4y ago
      Per my response to OP, I've been convinced on this.
  - quesera 4y ago
    "SHOULD" has a very specific meaning in RFCs. Contrast to "MUST". Unless the user can fix the problem, and you want them to try, an explanation of a 5xx error adds no value. Again, I don't think 5xx is ever a valid response from an API -- it's always a server-side error (code or infrastructure) that needs fixing, often with high priority. In many environments (e.g. medical, financial, or other secure/private), providing details on server errors is strongly discouraged. Even when the data isn't sensitive, I think you're asking for trouble by broadcasting server-side problem details to users.
    - d1sxeyes 4y ago
      Fair enough. You've convinced me on this - especially on the 5xx I think it's a very good point that a description of the error could potentially have undesirable consequences. I think my original point stands though, that status codes do tell you about the body in some circumstances. Or SHOULD tell you something about the body at least :)
revscat 4y ago
The spec may say one thing in this context, but that is only guidance. Technically, the response header says nothing about the body: they are entirely separate things. You can have any response code, and a body may or may not be present, regardless of the spec. So yes, it is correct to say that response codes say nothing about the body.

quesera 4y ago

> 400s and 500s SHOULD have a body I agree about 4xx bodies, generally. They indicate that the request was malformed or unsuccessful in some way. The requester can fix this problem. I think a 5xx should always represent an error on the server side that the requester cannot fix. It is always a bug or system failure to return a 5xx, which should be fixed by the API operator. Therefore no details are required or desirable to return to the requester.

d1sxeyes 4y ago
That may be your opinion, but the spec is clear: 6.6 [...] Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation[...].
- dragonwriter 4y ago
  SHOULD is not MUST [0], and “The user can do nothing about the problem and is likely to experience negative utility from any attempt to provide more detail than what the status code provides” is arguably a valid reason not to send a body with 5xx status responses. [0] https://www.rfc-editor.org/rfc/rfc2119.html https://www.rfc-editor.org/rfc/rfc2119.html
  - d1sxeyes 4y ago
    Per my response to OP, I've been convinced on this.
- quesera 4y ago
  "SHOULD" has a very specific meaning in RFCs. Contrast to "MUST". Unless the user can fix the problem, and you want them to try, an explanation of a 5xx error adds no value. Again, I don't think 5xx is ever a valid response from an API -- it's always a server-side error (code or infrastructure) that needs fixing, often with high priority. In many environments (e.g. medical, financial, or other secure/private), providing details on server errors is strongly discouraged. Even when the data isn't sensitive, I think you're asking for trouble by broadcasting server-side problem details to users.
  - d1sxeyes 4y ago
    Fair enough. You've convinced me on this - especially on the 5xx I think it's a very good point that a description of the error could potentially have undesirable consequences. I think my original point stands though, that status codes do tell you about the body in some circumstances. Or SHOULD tell you something about the body at least :)

revscat 4y ago

The spec may say one thing in this context, but that is only guidance. Technically, the response header says nothing about the body: they are entirely separate things. You can have any response code, and a body may or may not be present, regardless of the spec. So yes, it is correct to say that response codes say nothing about the body.