3 ms·
Last year worked with a variant of this. Status 200 always with in the message body the actual status code and message. Whyyy.
by bastijn 9y ago
Last year worked with a variant of this. Status 200 always with in the message body the actual status code and message. Whyyy.
- abraae 9y agoFrom memory Facebook popularized this approach way back when.
- dehrmann 9y agoThis can make sense when you're doing batch requests and allow partial failures. I wish there were a standardized way of making batch requests--maybe even HTTP-level support. (It isn't such a big deal with HTTP2)
- rhizome 9y agoThis can make sense when you're doing batch requests and allow partial failures. Wouldn't that be a 206?
- detaro 9y agoNo, 206 is only used with Range requests, when you try to get only some of the bytes of a larger resource. There is 207, I think created by WebDAV, where you give back an XML document detailing the status of sub-requests. I feel like that'd be confusing in many contexts as well, and a clearly defined custom response is probably easier to handle for the user.
- pavel_lishin 9y agoSuccessful response? 200 and a JSON payload. Error response? 200 and a human-readable string describing the error.
- bastijn 9y agoYes, the idea is indeed a signal that the request was received and the message the actual response. Problem is, if you are going to send me the actual HTTP status code in the 200 response with no additional information, you might as well send directly. Works better with all the libraries as well. Now we had to write a layer of abstraction to pull the actual message and code an forward that into our applications and third party libs. Personally, I prefer APIs that adhere to the HTTP status codes as defined in the standard.