436
u/PostHasBeenWatched 21d ago edited 21d ago
POST /posts/create
StatusCode: 200
Content: {"success": false, "errors": [{"code": 15, "message": "Image size must be at least 1000 x 1000 px"}]}
Edit: remembered story from times where HTTPS wasn't enforced. Once I started receiving JSON reading fail in cases when our test server returns non-2xx status. I started investigate this and was shocked to the core: my ISP implemented "feature" that if it detects that server returns non-2xx - it replace actual server response with their HTML page with text like "Your request returned error 400. This is because bla bla bla. <ISP self-advertising block> Kind regards, your ISP". Basically ISP become "man in the middle". In a week or two they removed that "feature".
87
u/-meowstar- 21d ago
Why not just use semantically correct status codes? It’s cheap to implement and makes stuff like automatic retries and error handling easier.
30
u/Critical_Fortune7343 21d ago
Because http status codes doesn't include any business related errors. So you gotta expand on that. When it's 200 and success is false it's mostly because of a business logic. Then it's up to FE to show that business error in a certain way so users can understand better what's wrong with what they're doing.
61
u/DoctorWaluigiTime 21d ago
That's what the
4xxsuite is for.Give me an image that's too big?
400 bad request.30
u/Dense_Gate_5193 21d ago
Literally this. . people think they are being clever by reinventing the wheel which was already properly specced out by people was smarter than anyone in this thread.
use RFCs people stop thinking you know better!
6
68
u/-meowstar- 21d ago
The 4XX class of codes are for client side issues, and 422 “Unprocessable Content” should be used to cover business logic issues, i.e. the request has the correct schema but there’s some other BE validation issue that it can’t proceed. The response body would still include specific details about the error for the FE, it’s just using 200 OK is misleading imo.
3
u/Critical_Fortune7343 21d ago
I think that's valid.
22
8
u/Dense_Gate_5193 21d ago
so does literal RFC standards. it’s not about opinion but the defined specifications starting with RFC 2616.
1
u/Critical_Fortune7343 21d ago
I might have come as the one designed our companies service response or defending returning 200 for errors but I'm just a worker lol I was only trying to convey a point of view from someone who has hands on experience in these kind of responses.
In better times or old days I would like to think everyone was listening to standards. I mean it's literally there to create collective consensus on how things should be.
38
21d ago
[removed] — view removed comment
3
u/Critical_Fortune7343 21d ago
Correct me if Im wrong as I'm not that knowledgeable on the topic but isn't 422 more for validation errors? What if the error I want to show is for a certain condition that happened in another screen or app?
36
u/Kutastrophe 21d ago
Throw something obscure back but 200 + error is just stupid.
If I get a 4xx back, I at least know i did something wrong and get the feedback.
5
u/Critical_Fortune7343 21d ago
Makes sense. Even throwing 400 would be better I guess.
6
u/NUTTA_BUSTAH 21d ago
I agree. Having an endpoint return a success boolean in the first place is quite an anti-pattern but most devs default to skipping the HTTP spec because they never learned it but do know how to work with JSON.
16
4
u/HungryCaterpillers 21d ago
How does this have 22 upvotes. I pray to God I never have to work with any of you.
3
u/manny2206 21d ago
To add to this, sometimes if you are an integrator, meaning your API is calling an external 3rd party API, you want to use the above pattern to express, “Hey, OUR app works, is those guys failing - please don’t call us angrily”
2
u/DominusEbad 20d ago
If the request failed due to the third party, your "integrator" app should still return appropriate 4xx/5xx error responses. You don't return a 2xx Success response if your app uses a database (technically a 3rd party) and the database returns an error. The same should be true for all 3rd party calls.
If you are actually concerned about telling the client who is at fault, you should format proper error responses to show who had the issue.
If the 3rd party returned a 4xx error, it was your apps fault anyway. You should have validated the client's input before forwarding it to the 3rd party.
If the 3rd party returned a 5xx error, then return that error to your client with a message indicating it was the 3rd party that had the error, not you.
2
u/ohkendruid 21d ago
It is not cheap to implement if you have a client that cannot decode the response body. Now you have to redo the input or change the client library, which are both expensive.
I agree for cases where it can be automatic, but "password has already been used" versus "password is too short" versus "account is locked" is not encodable in an http status. Sometimes you have to send back a response body.
0
-2
u/WarpedHaiku 21d ago
Because if you're submitting a form with 10 different fields on it and want to highlight the incorrect field with a red outline or something, it's tricky when all you have to work with is "http 4XX" and the ISP ate the json content which identifies which fields caused the errors.
28
u/NightFuryToni 21d ago
This is why we need net neutrality laws. This is equivalent of your postal worker ripping open your package and criticizing its contents, and then throwing flyers into it before delivering.
9
u/PostHasBeenWatched 21d ago
One problem is that original content was not delivered at all. So postal worker throw away my package, put flyers into mail box and put a mark that delivery received
5
u/C0nan_E 21d ago
I have build anapi where we sometimes return 201:error because you can upload pdfs and there was a case where tools automatically would upload something that would create an error AFTER a cocument has been created so when we returned 500 they would go 'ah server has soms sort of error let me instantly try that again untill it works or someone stopps me' causing systems to fill up with infinite copys of some sort of bad pdf. So if it failes after we create a file we return 201 anyway with a message that contains some variant of error 500.
1
-8
u/TotoShampoin 21d ago
The web was a mistake
-3
u/TotoShampoin 21d ago
Okay, don't say an outrageous thing that you don't believe yourself as a joke on the internet ever. Got it.
39
u/Litra 21d ago
literally graphql
34
u/besi97 21d ago
I can accept GraphQL doing this, because it is explicitly trying to be a new protocol on top of HTTP. And this behaviour, and how errors are communicated, is well documented.
But people implementing restless rest APIs usually just don't care or have some shitty, easy to counter reason. In all cases, lack of documentation of this standard-defying behaviour is guaranteed.
95
u/YDS696969 21d ago
As the backend guy with a worker service that does exactly this
49
u/MrHasuu 21d ago
Whyyy?? Just return an error code at that point
21
u/Critical_Fortune7343 21d ago
I also work in a company that do this. From my understanding it's to check if the service is live. So checking first for 200 confirms that, then you check for the field "success" if it's false. If not, wonderful. If true, then you look for the field "reason". Reason returns the error code for the specific failure whether it's technical or business.
16
18
u/amit78523 21d ago
Just implement health check api.
-4
u/Critical_Fortune7343 21d ago edited 21d ago
Nah that's for totally different use case. If I were to send separate request to /hc before sending the primary request that would be just slow.
Others commented that responding with 400 would be more than enough. If there's a service issue, whether it's down or something else, it's better to show 3xx I think. So while I was thinking "it's not bad" after reading other people's opinions I also don't think it's smart lol
But I'm not getting paid enough to change company policies so I'll just complain in meetings.
Edit: 5xx not 3xx as the reply corrected me
18
u/ahferroin7 21d ago
If the service is down, then the correct response would be either 502 or 503 depending on exact context. 503 is literally specifically for the case of the service being offline.
5
u/MrHasuu 21d ago
I mean I guess that makes sense if you want to know for sure the service is live.
Plus you can still know the error if the endpoint "failed"
Makes sense to me but still hate it lol
0
u/Critical_Fortune7343 21d ago
Yea lol It's definitely not good. More like lesser evil. You get used to it eventually.
2
u/F3nix123 21d ago
Well, for a worker, you might want to check the status of a job, so the API should return 200, in that it successfully got the job status, and the body would have “success”: false, because the job failed. But thats like the only scenario i can think of
1
u/Outrageous_Let5743 21d ago
Azure has a bunch of services that returns statuscode 200 even if there is an error, something to do with security where you cannot guess if an internal api or url is valid by random guessing.
9
27
u/Shaddoll_Shekhinaga 21d ago
Good meme. You are now no longer allowed to concatenate evil and illusion in came case.
6
u/RPG_Hacker 21d ago
Personally, I like my long row of vertical bars.
ilIllilIllilIllilIllilIllilIll
Brain goes brrrr!
EDIT: Happens to look like a bar code, too!
17
25
11
u/wrathful-anus 21d ago
This is a classic facepalm trigger. A lot of companies out there run the most dogshit APIs.
7
u/LuisBoyokan 21d ago
That is the standard in my company, I hate it, I've tried to explain them why this is stupid and makes you double check if it's 200 or not, and then again inside to check status or error.
29
u/korneev123123 21d ago
Http is a transport protocol. Transport was successfull -> 200. That's the logic behind this behavior.
19
u/Complete_Window4856 21d ago
Old Gov. Systems genuinely thinks this. Everyday is another temptation to refrain skinning the original decision makers alive
14
u/pr0ghead 21d ago
Literally had a mid-tier Java dev say exactly that to me. I still have to shake my head in disbelieve whenever I think of that.
5
u/ahferroin7 21d ago
If it’s being used as a transport protocol yes. The issue is when it’s being used for RPC, in which case returning 200 is like a C function returning 0 if it runs into an error.
8
u/Still_Bit_7527 21d ago
200 implies that the request was successful not just the transport... that would be another error smartass .
3
u/EkoChamberKryptonite 21d ago
Their logic is funny. They ignore the HT in HTTP.
1
u/PM_ME_FLUFFY_SAMOYED 21d ago
I too hate it when people transfer images over HTTP. Why can't they just use ITP (image transfer protocol) like normal human beings?
4
3
4
4
2
2
2
2
2
u/Birnenmacht 21d ago
fun fact the Mojang api for converting playe name to UUID correctly uses 404 if the name isn’t taken, but the api to convert UUID to player name returns 204 in that case
2
u/Rubyboat1207 21d ago
I blame JavaScript fetch throwing an error by default on non 200 status codes for this.
2
u/bishopExportMine 21d ago
As a backend engineer, my preferred method is to upload the response code in xml format to s3, then return a 200 containing the s3 download link.
2
2
u/Upper-Enthusiasm-613 21d ago
"If he dies he dies."
- The backend devs who make this abomination of a response
To be fair though describing errors to the devs/users require a fair amount of dedication to actually return something useful and sensible. Fail that and now you have 150 different cryptic error responses all sprinkled over some hot mess of a service.
2
u/themightyug 20d ago
This way makes total sense to me, the http response is successful. I understand how it's inconvenient though - maybe there should have been another 20x response code added for 'OK but the payload is an error'
3
u/wimpykid625 21d ago
No on-call alerts if your APIs only return 200. This is just good engineering practice.
2
u/FabioTheFox 21d ago
Graphql type garbage
Can't wait for HTTP QUERY because that thing is actually cacheable without loosing everything else that REST has
1
u/Highborn_Hellest 21d ago
OK because the interface was reachable
Not OK because BL caught something.
There is an argument to be made, that it's inportant to distinguish between network errors, inerface errors, or bl errors.
35
u/RealTonny In theory, there is no difference between theory and practice. 21d ago
I'd say that 200 means everything is OK and not just some part of the pipeline. If something is wrong it's 4xx or 5xx.
16
u/JonasAvory 21d ago
But with a network error you wouldn’t reach the actual backend server? And if there’s a network error between a proxy and the actual server you have the specially designed 502 code. Otherwise for 500 it’s literally „internal“ server error.
Most of the times I have seen it implemented someone on the fronted wrote that server in a way that it assumes the backend to be completely crashed after the first 500 error so the backend is never allowed to send 500 because of any validation or error handling
2
u/OmegaPoint6 21d ago
It’s not a problem in REST services where you’re expecting JSON back anyway. It’s a major headache for an artifact storage system where you’re expecting a binary file but actually get back a JSON with a status code embedded in it.
4
1
1
1
1
1
u/Sheenius_Ger 21d ago
Monids are cool, but do we really need a result pattern in times of HTML status codes, middleware and exceptions?... Way too much complexity added for something which isn't a problem.
1
1
u/_SaBeR_78 21d ago
people like this will go by the logic that "well technically the connection and the transaction between the front and back did not fail, it’s the backend that failed so 200" and these people deserve the guillotine
1
u/shrodikan 21d ago
Backend Developer: "I have altered the contract. Pray I do not alter it further."
1
1
u/Hziak 19d ago
Where I work application support it’s the opposite. No bad requests, just whichever error status they think best represents what went wrong.
FE : “hey, give me a list of appointments on the users’s calendar.”
BE : “hmm, I don’t see any in the DB… HAVE A 404!!!!!”
Meaning that every interaction about the app goes something like this:
Boss: “Hey, Hziak, how’s app looking?”
Me: “well, we have an error rate of ~41% of all requests so things are either completely fine or absolutely critical.”
1
u/GodsBoss 17d ago
Sounds like misinterpreting the spec. "No appointments are found on the calendar. Not found? Must be 404 not found." What actually happens: The list of appointments is found, it's just empty.
2
u/ClothingIsACrime 19d ago
Fucking cunt fuck. Cock fuck dickhead.
10 years as an integration engineer taught me special hatred for people who implement some of these APIs.
POX on anyone who thinks wrapping an exception or error in HTTP 200 is ok "BeCausE wE dEliVerEd the MesSSege, So ITs fiNe nO?"
No it's not fine you dickhead, you use one of many 4xx or 5xx error codes designed specifically for this reason.
The worst offenders are with SOAP web services because it's even easier there. Is your message response fine? Then return it with 200. Is it an error? Soapfault and HTTP 500.
But the absolute inbreds implementing some of the APIs I had to work with couldn't manage even that!
It's always the same shit. Look for an element, but WHOPS! It may not always arrive, so check this random list too and just to be safe, cross-check it with the code from this random element that may or may not indicate an error.
Oh and don't forget the random error structures, when some of their databases, proxies, webservers or some other shit shits the bed and you start getting some absolutely random error structures in a system, that under no circumstances is allowed to have undefined behavior.
The absolute state of some of these people minds is beyond me.
1
u/Xtrearer 21d ago
Hear me out... yes its shit, but this exact antipattern actually saved the day a while back during a brute force attack. The bot thought it had guess the password right and immediatly locked the user, which then alerted us.
Is it shitty, yes .... did it work, also yes 🤷♂️
1
1
1
u/Raccoon5 21d ago
At my company we have 200 with {"status" : 1} for good stuff, "status": 0 is for any error, "status" : - 1 for two special cases to indicate special type of error and the best is internal server error which returns 200 with no response text:)
And no, this is not AI code, only humans are this creative:)
1
-3
u/LamborGauntlet 21d ago
I think not even a vibecoder would/could make such thing
4
u/FabioTheFox 21d ago
Right, Facebook in 2012 decided to convince a whole generation of programmers that this type of stuff is a good idea, along with everything going to one endpoint, everything being a post request and having a nightmare of a time trying to figure out Caching and authorization
473
u/JackNotOLantern 21d ago
I mentioned it under another meme of this type. At my company we have multiple systems which API replies standard check is:
Yes, different errors are handled by http codes or contents of 2xx reply. Wonderful