Timeline for Why do so many standards for JSON API response formats contain a "success" property in the response body instead of just using HTTP status codes?
Current License: CC BY-SA 4.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 27, 2022 at 3:00 | history | tweeted | twitter.com/StackSoftEng/status/1507915445352943618 | ||
| Mar 25, 2022 at 13:48 | comment | added | bendataclear | I use both HTTP status and a JSON body success and error message, the JSON message allows more details about the exact problem, and the HTTP status code shows a general failure, these general failures show up in the browser console as well as server monitoring so are a better way to spot problems. | |
| Mar 25, 2022 at 13:00 | answer | added | CodeCaster | timeline score: 0 | |
| Mar 25, 2022 at 10:12 | answer | added | AnoE | timeline score: 0 | |
| Mar 24, 2022 at 15:53 | comment | added | Darren Ringer | @Alexander I think you've gotten at the heart of it, the HTTP status code is an entirely different conceptual layer from the JSON response. Just as the TCP acknowledgements are, which we don't even expect to see. It just so happens that in many applications the HTTP status code is read a few lines away from parsing the JSON. | |
| Mar 24, 2022 at 14:56 | comment | added | jrh | Not an answer but some companies say "you can only use certain return codes", which forced me to return a specific return code and then put the error information in the JSON. I thought that was silly and annoying, but it was mandated company wide and required to deploy anything. | |
| Mar 24, 2022 at 12:51 | answer | added | csstudent1418 | timeline score: 1 | |
| Mar 24, 2022 at 12:27 | comment | added | htmlcoderexe | @U.Windl I know what you mean - I think the names are technically incorrect but you get the point across. It's been a while for me too... | |
| Mar 24, 2022 at 12:25 | comment | added | U. Windl | Basically the HTTP status can be seen as the status of the "transport layer", while the JSON status response is from the "application layer" (note the double-quotes; no nit-picking, please!) | |
| Mar 24, 2022 at 12:23 | comment | added | htmlcoderexe | It's different layers, that's all. You wouldn't put the TCP handshake status in there either, right? | |
| Mar 23, 2022 at 19:54 | comment | added | Joshua | @Alexander: I don't see why you would keep these. I found it a better design to generate them at one end of a pipeline and consume them at the other; if the response is large enough the whole thing is never materialized in RAM at once. | |
| Mar 23, 2022 at 16:09 | history | protected | gnat | ||
| Mar 23, 2022 at 15:14 | answer | added | user412514 | timeline score: 18 | |
| Mar 23, 2022 at 13:20 | history | became hot network question | |||
| Mar 23, 2022 at 13:16 | answer | added | Paul Bissex | timeline score: 6 | |
| Mar 23, 2022 at 8:21 | vote | accept | Šime | ||
| Mar 23, 2022 at 6:54 | answer | added | gnasher729 | timeline score: 111 | |
| Mar 23, 2022 at 1:45 | comment | added | Alexander | Relying on HTTP status codes only works if every "link in the chain" is HTTP. The moment this payload gets saved to a DB, enqueued to a message queue, etc., then HTTP status codes no longer exist, so you end up need to fold them into your payload, anyway | |
| Mar 22, 2022 at 23:23 | answer | added | AIWalker | timeline score: 58 | |
| Mar 22, 2022 at 16:27 | review | Close votes | |||
| Mar 27, 2022 at 3:01 | |||||
| S Mar 22, 2022 at 16:01 | review | First questions | |||
| Mar 22, 2022 at 17:49 | |||||
| S Mar 22, 2022 at 16:01 | history | asked | Šime | CC BY-SA 4.0 |