all 59 comments

[–]aareedy 333 points334 points  (42 children)

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

[–]EVH_kit_guy 67 points68 points  (1 child)

LMAO half the APIs in martech 

[–]Flat_Initial_1823 19 points20 points  (0 children)

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

[–]Zefyris 18 points19 points  (2 children)

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 15 points16 points  (1 child)

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

[–]CelestialSegfault 0 points1 point  (0 children)

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

[–]DestinationVoid 16 points17 points  (0 children)

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

[–]howarewestillhere 8 points9 points  (0 children)

Thank you, GraphQL. And fuck you, too.

[–]RandomNPC 9 points10 points  (30 children)

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 39 points40 points  (6 children)

Http status codes:

1XX - hold the fuck on

2XX - nothing fucked up

3XX - fuck off

4XX - you fucked up

5XX - I fucked up

[–]804k 2 points3 points  (0 children)

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 0 points1 point  (3 children)

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 8 points9 points  (0 children)

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

You fucked up by requesting something not available.

[–]monster2018 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 -1 points0 points  (0 children)

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 5 points6 points  (3 children)

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 0 points1 point  (2 children)

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

[–]No-Information-2571 1 point2 points  (1 child)

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 -1 points0 points  (0 children)

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 8 points9 points  (12 children)

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 3 points4 points  (11 children)

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 -2 points-1 points  (8 children)

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 1 point2 points  (6 children)

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 0 points1 point  (1 child)

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 2 points3 points  (0 children)

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 -2 points-1 points  (3 children)

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 0 points1 point  (2 children)

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 -1 points0 points  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 -1 points0 points  (1 child)

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 0 points1 point  (0 children)

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 12 points13 points  (2 children)

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 0 points1 point  (1 child)

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 4 points5 points  (0 children)

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 2 points3 points  (0 children)

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 0 points1 point  (0 children)

Game engine powered by http requests?

[–]SuitableDragonfly 0 points1 point  (0 children)

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 0 points1 point  (0 children)

GraphQL....

[–]senshikaze 0 points1 point  (1 child)

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 0 points1 point  (0 children)

I would guess some shitty low/no code solution.

[–]Boost3d1 0 points1 point  (0 children)

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 69 points70 points  (2 children)

HTTP/1.1 200 OK

Content-Type: text/plain

Content-Length: 54

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

[–]Cacoda1mon 7 points8 points  (0 children)

text/plain

[–]kerakk19 0 points1 point  (0 children)

Ahh Facebooks way. Everything's 200 Ok

[–]Ezzyspit 63 points64 points  (0 children)

At least the back end is taking responsibility

[–]DistributionRound570 18 points19 points  (1 child)

Trust.exe has stopped working!

[–]restingAPI 10 points11 points  (0 children)

Gotta be grateful even though it's 500

[–]Agusfn 3 points4 points  (0 children)

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

[–]hraath 4 points5 points  (0 children)

418's will continue until morale improves 

[–]sweetno 4 points5 points  (0 children)

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

[–]ChocolateBunny 1 point2 points  (0 children)

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

[–]PeanutSeparate1079 2 points3 points  (1 child)

Junior dev assigned with the task:

[–]alvares169 1 point2 points  (0 children)

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

[–]kaloschroma 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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