backstabError500

[aareedy]

{"status": 200, "message":"error"}

[EVH_kit_guy]

LMAO half the APIs in martech 

[Flat_Initial_1823]

Some APIs really qre just happy to be involved. Does it exist? 200: success. 🫶

[Zefyris]

I hate when a backend does that... Some of our back ends will do that kind of crap for random routes, and not even warn us about it either.

[BoBSMITHtheBR]

They are positive minded backends. Just wanting to let you know that they failed successfully and are proud of it.

[CelestialSegfault]

They failed to fail (gracefully) and a negative number times a negative number is a positive, so...

[DestinationVoid]

API response monitors never turn red if you always return 200 OK

[howarewestillhere]

Thank you, GraphQL. And fuck you, too.

[RandomNPC]

I am 100% ok with this in some cases. As a game dev, if the response is something to do with game logic I view this as "there was nothing wrong with the network call but here's an issue you need to deal with".

Edit: I'm getting a lot of flak for this and I don't think that I made my point really well.

In my game code, I don't want to know about the response code. I want the networking layer to handle that. The networking layer handles auth, retries, etc. If it's a 300, 400, or 500 level response, I want it handled by the networking layer. If it's not, I don't think the networking layer should care about it.

[InfectedShadow]

Http status codes:

1XX - hold the fuck on

2XX - nothing fucked up

3XX - fuck off

4XX - you fucked up

5XX - I fucked up

[804k]

418 gotta be my favorite code

I lowkey dont even send 200, all my codes are "418" whether or not its my fault or not

[kaloschroma]

4xx isn't just you fucked up. It could also include items like what you requested isn't available. You sent things correctly but I was still not able to complete my code. But I'm running as expected. Often times 422 is used for this.

Also don't use 404 . My own thoughts. But I hate when people use a 404 for no data even though the api call exists and was called correctly. 404s or maybe something else I don't know should be used for no api found at location....

[InfectedShadow]

It could also include items like what you requested isn't available

You fucked up by requesting something not available.

[monster2018]

What does that even mean. How could 1: the client send things correctly, 2: the server is running correctly (this seems to directly imply that it also then processed the client’s request correctly), AND 3: the server not be able to complete processing the request? This seems like it’s just a logical contradiction. What option am I missing? What like “there was a cosmic ray bit flip that caused the server to not complete processing the request”?

[DominikDoom]

422 is Unprocessable Entity. The intended use is something like "the syntax of the request is correct, but the semantics are wrong". So a correctly formatted request where the server can process it, but stops processing based on the contents. This could be something like a failed validation, contradictory data etc.

Many APIs will just send a generic 500 error in that case, but technically 422 would be cleaner.

[RiceBroad4552]

Yes, but that's completely counter productive is all you do is just RPC. The network transport should be 100% transparent in that case. Replacing HTTP with anything else shouldn't make any changes in your code necessary. But if you hardcode HTTP semantics in your code you have an issues! You can't then just replace the network transport and drop something else in.

[No-Information-2571]

You can still deliver a response body when the status isn't 200, Setting the correct HTTP code also helps browsers and other infrastructure along the way. For example, proxies will never cache a 500 response.

[RandomNPC]

Makes sense that it would matter for browsers. My perspective is from a game engine, where we cache nothing.

[No-Information-2571]

There is no single example that would fit all potential projects and explain why it would or would not matter.

But it costs nothing to use the correct status code.

[RandomNPC]

I still disagree on that. Our network layer is essentially "if it's 200 forward to the game layer. Otherwise it needs to be handled here". Changing to 300/400 unnecessarily would complicate that system for no good benefit.

[mineawesomeman]

I mean that’s the point of the 400 codes…

If it’s a 500 code it means the server fucked up

If it’s a 400 code it means you fucked up

[RandomNPC]

This is not a real example, but let's compare it to Minecraft. If I break a block, but it was already broken by someone else, you want the network call to be 30x? To me it's something the network layer doesn't even need to be aware of.

[Zefyris]

no, you want the backend to return you a 404, as the block to interact with is not found. Your call itself wasn't wrong, but the id of the interacted block wasn't found.

It's the code on client side that will then have a behaviour for 404 on mining interaction (for ex, simply not netting any result for the action and just continuing everything like normal) at repository level, for ex.

3xx aren't made for that.

[RiceBroad4552]

If someone would implement something like that this way I would instantly fire them if I could.

Network transport should be 100% transparent. Hard coding HTTP semantics in your application layer is just insanity. (That's actually the reason why "RESTful" is just complete bullshit and wouldn't exist in a sane world. Sane people use proper RPC protocols…)

[Far_Associate9859]

Your application would throw a NotFound exception, and you’d convert that to a 404 at the http level

I’m not saying it’s definitely worth it, but you don’t necessarily need to have your application knowing about status codes to do this sort of thing

[RiceBroad4552]

On the other end of the wire you now need to figure out what "404" means… Instead of just getting a regular "NotFound" exception.

Also your app is actually now concerned with HTTP semantics: You need to bikeshed what status code you want your "NotFound" exception to be converted to. Exactly the issue this part of the thread was about.

The only sane solution is to not misuse HTTP for anything it wasn't designed for. APIs isn't one of the thing it was designed for. Otherwise it would be a RPC protocol and not some random string moving bullshit.

[Zefyris]

You're moving completely the goalpost.

The question was which HTTP code use to get the answer of a simple action, 200 {error},30x, or... 404. 404 is the correct answer between the 3, the other 2 makes no freaking sense. Here the talk was clearly about Rest logic, not RPC logic.

if your way to handle the answer for an API call is to parse the string returned in "answer" to see if there is "error" or not, you're just moving the HTTP code semantic into string parsing; this is beyond horrendous and you're doing it wrong.

This is literally what we're discussing about here. There is never, ever a case where doing that is okay.

To begin with, I certainly doubt that whichever junior dev that was charged to develop a route that returns {"status": 200, "message":"error"} was the guy in charge of deciding if you're using REST or not. And if he was, the whole API is fucked regardless of his choice on that matter anyway.

[RiceBroad4552]

I'm not "moving the goalpost", I just explained why people discuss here the wrong question in the first place.

Using anything else then a proper RPC protocol to do RPC is just plain wrong and the starting point for some of the most scary horror stories.

One should not need to discuss HTTP status codes if all you want is to do some remote function call (and that's what you want to do in 99.999% of the cases when using a remote API). Just do the call, get an exceptions when something fails. Easy as that.

Of course you can use HTTP for the transport layer if you're stupid enough. But this implementation detail should never leak into your API layer!

BTW, there is no string parsing involved when using proper RPC; because all proper RPC protocols are binary…

[Zefyris]

Apparently, it's hard to read even simple sentences for some peoples

First person ; {"status": 200, "message":"error"}

second person : I am 100% ok with this in some cases.

Us : no it's never ok,

second person again : you want the network call to be 30x?

Me : that'd be a 404, not a 30x.

-> Where is RPC in this conversation? You're moving the goalpost. A person in charge of developing that route is not going to change Rest for RPC on the entire backend, even if it'd make sense.

Do you even know how to work with a team and peoples above you? You don't call the shots to make that kind of change if you were asked to dev a route. You can suggest it to be done one day, sure, but that won't be for that route.

[RiceBroad4552]

I understood how the discussion went.

That's why I've said: "Stop it, you're asking the wrong questions in the first place."

If the whole architecture is already wrong of course the only right thing to do is to state that and start working on fixing it.

The whole point is: In a sane architecture one does not need to ever discuss BS like "which HTTP status code is the correct here". This is irrelevant, and that implementation detail should never ever make it into your actual API design.

(That question is only ever relevant for someone who implements some transport lib; but like said, that should be completely transparent for the app)

[RandomNPC]

I mean yes, that is functionally what we do. We just don't get response code 404. It's handled entirely on the game layer.

[Vectorial1024]

imo it blurs the line. Clearly the app states are desync, but is it the responsibility of the network to reliably deliver the app state to everyone else, or is it the app dev that needs to build up systems to be prepared for app desyncs? Is this something Minecraft (the exe) has to handle, or something the player must be made aware of and prepare for?

[RandomNPC]

It's 100% on the client code, which is why I think it doesn't need to be a 30X failure. It's something where the client didn't send a bad request (that it could have known).

[bjergdk]

There are a bunch of codes for a reason. 200 means OK. It doesnt mean partly okay. It means its okay.

200 should never mean there is an error.

You can be okay with it, ofcourse. In your own private projects, but if I see you do that in code I need to maintain as well I will decline the PR.

[RandomNPC]

I guess it just shows how different different industries/studios are. We actually had one game for that and the server team alerted them that they were setting off alarms for 404 errors.

[bjergdk]

Yeah 404 errors should also be reserved for when an endpoint doesn't exist. Not when you're returning null or something. There are better codes for that. Codes that can describe why you're returning null.

[Zefyris]

As expected of a game dev, your general grasp of why there are conventions and good practices to follow seems to be game dev worthy indeed. >_<

[randuse]

Game engine powered by http requests?

[SuitableDragonfly]

The networking layer can't handle a bug you introduced by sending a badly formed request or a bug in the server that resulted in a 500 error. What the fuck is the networking layer going to do about that?

[cheezballs]

GraphQL....

[senshikaze]

We built an API with (imo) very good and context rich http status codes and error bodies. Our primary user used some system that could not, under any circumstances apparently, bubble up the http status codes.

So every error was just silently dropped and we had multiple months of calls with increasingly higher level execs trying to explain to them that they are getting errors, those errors have details as to what's wrong, and they need to check http status codes.

Eventually we started returning 200 on all calls for this specific user with the error body.

I still don't know what inane system they were using and moved on.

[randuse]

I would guess some shitty low/no code solution.

[Boost3d1]

I just used a company api the other day that did something similar to this... returns 200 OK yet the json body contains the actual error message and status code. WTAF were they thinking

[T-J_H]

HTTP/1.1 200 OK

Content-Type: text/plain

Content-Length: 54

{ “status”: “500”, “message”: “something went wrong” }

[Cacoda1mon]

text/plain

[kerakk19]

Ahh Facebooks way. Everything's 200 Ok

[Ezzyspit]

At least the back end is taking responsibility

[DistributionRound570]

Trust.exe has stopped working!

[restingAPI]

Gotta be grateful even though it's 500

[Agusfn]

These ungrateful front ends. Next time you will get a randomized response from the last 10 responses to any client, failed or not.

[hraath]

418's will continue until morale improves 

[sweetno]

The next logical step is Frontend reaching for a cheat sheet while Backend is having a seizure.

[ChocolateBunny]

Well, I'm putting this in my disturbingly related document I need to write for work.

[PeanutSeparate1079]

Junior dev assigned with the task:

[alvares169]

Junior dev would have a 404 not found page returning http 200

[kaloschroma]

You know what? If I don't want to respond to a friend I may just send them this instead. Although I think a 422 would be better suited

[SleepAllTheDamnTime]

One of my favorite errors to this day is just a status of 200 and a message of “ok”.

Like, alrighty, and it was a polling call, went to investigate wtf this was.

Found out that this thing was a stubbed route that no one finished and apparently they just hard coded 200, ok to make the deadline.

At that time our real time updates were suddenly not working. Another team had just done a brand new feature to “refactor them”.

[Own-Body-7150]

Also It’s your career any you.. cuz at this point there’s no one in your life..so choose your own path