6 ms·

ah, yes, completely separate. HTTP code: 200 ok Body: {"error":"internal server error"}

deleted 2y ago
[deleted]
bb88 2y ago
My favorite example of this was renaming a 500 error due to an unhandled exception to a 400 error to make it look like it was the error of the caller. Management was also possibly tracking 500 errors too, so the 400 could also have been gaming the system. In some mental models, though, it did make sense. Particularly the one that went, "Well, we never would have errored, if you never called us!"
- xmprt 2y ago
  It's somewhat fair though. If there's a case that would cause errors for the system and it's a case that you're not supposed to handle, then a 400 error sounds perfect for that case. For example, if you have a service and it panics/returns 500 when you pass in an empty user id, then you could instead return a 400 before you hit the panic and all is good.
  - bb88 2y ago
    Normally you should attempt to find all the corner cases and present the errors to the user -- before processing the request. If you can't do this, it's time to rethink how your api works. A good api is simple to use and simple to write. It also simplifies your business logic in that all the possible user defined idiocies are caught before your business logic actually processes the request. Some frameworks do this better than others. And rather than documentation, I tend to prefer comprehensive error messages.
    - fmbb 2y ago
      > Normally you should attempt to find all the corner cases and present the errors to the user -- before processing the request. That is what they are suggesting. You check the request and return 400 if it’s bad.
      - bb88 2y ago
        One example of a 500 error is a null pointer error. Was it a bad request or a logic error? One is your problem the other is not. Just returning a 400 hides that issue. Validating the payload before processing it simplifies the issue for everyone involved. A 500 error should be your problem with a stack trace in the log. A 400 error should provide enough description to tell the user it's theirs and how to fix it. Just marking recoding a 500 to a 400 because of a null pointer error would get noticed on a code review and marked up on a code review.
        bdangubic 2y ago
        400 - you fucked up 500 - we fucked up
saghm 2y ago
Honestly, my controversial take is that for APIs, it would be cleaner to not use any HTTP status codes other than 200 and have all of the semantics in the body of the response. I'm sure someone smarter than me will jump in and explain why this wouldn't work in practice, but it just feels like application semantics are leaking from a much more natural location in the body of the response. I feel similarly about HTTP request methods other than POST in APIs; between the endpoint route and the body, there should be more than enough room to express the difference between POST, PATCH, and DELETE without needing them to be encoded as separate HTTP methods.
- tayo42 2y ago
  Your kind of describing things like thrift and other rpc servers?
  - saghm 2y ago
    Possibly. I'm not sure why it should require switching to an entirely different protocol though; my point is that making an API that only uses POST and always returns 200 is something that already works in HTTP though, and I have trouble understanding why that isn't enough for pretty much everything.
    - tayo42 2y ago
      You need some kind of structured way to describe the action to take, what the result is or what the error is. so the client and server can actually parse the data. that's the protocol, whether its something formal like rpc libraries, or "REST"-ish or w/e json-rpc is probably what your describing over http, maybe if you squint enough graphql too
    - lll-o-lll 2y ago
      You are thinking like a developer, but there is a world of networking as well. Between your client and server will be various bits of hardware that cannot speak the language you invent. 200, 401, 500 — these are not for the use of the application developer — but rather the infrastructure engineer.
maccard 2y ago
Think about what the client code looks like to handle this and the alternative, particularly if you’re implementing an sdk and the api is an implementation detail. I’m not saying I would choose this path, but it certainly reduces the amount of code on both sides that you have to write.
ranger207 2y ago
If HTTP is your API's transport layer, then HTTP errors should be related to problems with the transport layer and not to API itself. Is the internal server error caused by a bad HTTP request or a bad API request?

deleted 2y ago

[deleted]

bb88 2y ago

My favorite example of this was renaming a 500 error due to an unhandled exception to a 400 error to make it look like it was the error of the caller. Management was also possibly tracking 500 errors too, so the 400 could also have been gaming the system. In some mental models, though, it did make sense. Particularly the one that went, "Well, we never would have errored, if you never called us!"

xmprt 2y ago
It's somewhat fair though. If there's a case that would cause errors for the system and it's a case that you're not supposed to handle, then a 400 error sounds perfect for that case. For example, if you have a service and it panics/returns 500 when you pass in an empty user id, then you could instead return a 400 before you hit the panic and all is good.
- bb88 2y ago
  Normally you should attempt to find all the corner cases and present the errors to the user -- before processing the request. If you can't do this, it's time to rethink how your api works. A good api is simple to use and simple to write. It also simplifies your business logic in that all the possible user defined idiocies are caught before your business logic actually processes the request. Some frameworks do this better than others. And rather than documentation, I tend to prefer comprehensive error messages.
  - fmbb 2y ago
    > Normally you should attempt to find all the corner cases and present the errors to the user -- before processing the request. That is what they are suggesting. You check the request and return 400 if it’s bad.
    - bb88 2y ago
      One example of a 500 error is a null pointer error. Was it a bad request or a logic error? One is your problem the other is not. Just returning a 400 hides that issue. Validating the payload before processing it simplifies the issue for everyone involved. A 500 error should be your problem with a stack trace in the log. A 400 error should provide enough description to tell the user it's theirs and how to fix it. Just marking recoding a 500 to a 400 because of a null pointer error would get noticed on a code review and marked up on a code review.
      - bdangubic 2y ago
        400 - you fucked up 500 - we fucked up

saghm 2y ago

Honestly, my controversial take is that for APIs, it would be cleaner to not use any HTTP status codes other than 200 and have all of the semantics in the body of the response. I'm sure someone smarter than me will jump in and explain why this wouldn't work in practice, but it just feels like application semantics are leaking from a much more natural location in the body of the response. I feel similarly about HTTP request methods other than POST in APIs; between the endpoint route and the body, there should be more than enough room to express the difference between POST, PATCH, and DELETE without needing them to be encoded as separate HTTP methods.

tayo42 2y ago
Your kind of describing things like thrift and other rpc servers?
- saghm 2y ago
  Possibly. I'm not sure why it should require switching to an entirely different protocol though; my point is that making an API that only uses POST and always returns 200 is something that already works in HTTP though, and I have trouble understanding why that isn't enough for pretty much everything.
  - tayo42 2y ago
    You need some kind of structured way to describe the action to take, what the result is or what the error is. so the client and server can actually parse the data. that's the protocol, whether its something formal like rpc libraries, or "REST"-ish or w/e json-rpc is probably what your describing over http, maybe if you squint enough graphql too
  - lll-o-lll 2y ago
    You are thinking like a developer, but there is a world of networking as well. Between your client and server will be various bits of hardware that cannot speak the language you invent. 200, 401, 500 — these are not for the use of the application developer — but rather the infrastructure engineer.

maccard 2y ago

Think about what the client code looks like to handle this and the alternative, particularly if you’re implementing an sdk and the api is an implementation detail. I’m not saying I would choose this path, but it certainly reduces the amount of code on both sides that you have to write.

ranger207 2y ago

If HTTP is your API's transport layer, then HTTP errors should be related to problems with the transport layer and not to API itself. Is the internal server error caused by a bad HTTP request or a bad API request?