3 ms·
I'd say returning 200 for all successes is reasonable if the responses are simple. Returning 200 for an error makes no sense. Having 400s and 500s is the simpl
by alganet 3y ago
I'd say returning 200 for all successes is reasonable if the responses are simple.
Returning 200 for an error makes no sense. Having 400s and 500s is the simplest way to have observability over protocol behavior (think logs, error rates, etc). If you use all 200s, you'd have to re-implement observability by yourself, so you lose simplicity that you gained by ignoring those statuses.
It's the same thing with caching stuff. You could implement those outside the protocol, but then you'd be writing your own protocol (trying to be smarter than decades of engineering efforts).
- sa46 3y agoI prefer to treat HTTP as a transport layer. A 200 means the transport succeeded but doesn’t indicate that the RPC succeeded.
- infogulch 3y agoThis makes no sense at all. "you got a response" means the transport succeeded, "it timed out" means the transport failed.
- sa46 3y agoThat’s a strong assertion. There’s plenty of status codes that indicate something bad happened at the HTTP level but don’t convey information about the RPC. - 404 might mean the URL was wrong - 405 might mean swapping POST with PUT
- jbverschoor 3y agoNot the http level… at the level above, the user of your api. Both of these are simple programming errors. You might as well have used the wrong host or protocol for that matter