200 OK
{ ok: false, error: "Not found", code: 404 }

This shit is more common than one would think

How to spot a dev that should be fired and removed from the gene pool.

Dont worry the exam wont be confusing

The exam:

What in the cinnamon toast crunch is this?

GraphQL?

Plus these API are usually buggy/inconsistent. {"ok": true, "error":"Some error message here", "code":"some generic code"}

@IntrusionCM so shoot their children as well if they managed to have any by accident?

@electrineer thought more of a very mean dick punch...

I think there's nothing wrong with this. As long as the response pattern is the exact same throughout the project.

Ey boss, do you wanna make our API RESTful?

Yeah man (*hits blunt*) but also like...... no, man.

Good, cus I don't know how to set the response code in PHP anyways, only the body, man. (*hits blunt*)

@TheCommoner282

Pun intended. :-)

@kiki - can you handle it on the frontend, backend dev is too busy! No they're just lazy stupid f#£ks! If he worked for me, he would be busy searching for a new job.

Its never ok to send 200 and then error: something happened, even if the correct code is sent in response object.

Never got the idea behind that pattern!

@devJs It is ok in some situations...

@Sid2006 it is never okay. It might be okay in websockets environments, but guess what! you don't have 200 OK and other HTTP codes there

@kiki here's my 2 cents on this matter, as a backend dev.

1. It's difficult to differentiate from the backend whether a non-200 status code (lets say 404) was thrown from the framework itself or the resource doesn't exist for that particular user. If we have a 200 OK status saying message: "Doesn't exist" at least I would know instantly that the API worked fine, or didn't which saves investigation time.

2. The frontend dev can just write one handler for it -> if ok is false then expect to have a message and show it in the toast. This allows the backend guy to put experimental code in the backend targeted at one particular customer (production testing). Now I shouldn't need to tell you that code behaves differently in local and production environments.

[CONTINUED]

3. If this standard is enforced both for the frontend and backend guy for that particular project, then its easy to have it. You wanna change it up, fine do it on the next project. We all change our code standards and style with years of experience. No point of beating urself up in the present.

4. The problem won't happen for scale. It's not a database normalization problem, that'll fuck u up in the long run. If the last function executed has its definition in one place (I hope) then its easy to refactor that to throw proper status codes, if the frontend dev is dying for it. It won't create a fuss.

blame react for it.

@Sid2006

1. Responses with error codes can contain bodies that clarify the error. Also, if the API didn't work as in your example, a 5XX code should be returned.

2. If a frontend dev can “just” write one handler, then a backend dev can also “just” return correct codes. It's not about toast messages. Fundamental things like API response codes mechanism should be defined very early on. They rarely change later. I don't want to subject every frontend dev that joins us in the future to “well, we don't follow REST here, write a handler”. There can also be multiple frontends — internal UIs, admin panels, mobile apps. Why should all of these devs cover up the backend team's incompetence?

3. See 2. Also, why enforce incorrect “standards”? Every framework in existence can return correct codes. You should go out of your way to break it.

4. Translation: “it's nothing major, we'll fix it later”. Why have this philosophy on new projects?

@Sid2006 your use cases 1 and 2 sound like debug code that should never leave the dev environment.

@kiki When we start using terms like "should be returned", it makes an argument about a perfect world where all standards and practices are followed, there are no such things called timelines, micro-management and every one gets paid a fat and meaty salary.

But the reality is something else entirely isn't it?

I have been screwed over by standards and practices enough number of times to compel me to come up with whatever has a little bit of standards and code readability and makes my job a lot easier to manage and debug.

We can argue all day about college concepts on Software Engineering but the reality is, managers / CEOS / Investors are money hungry and want to get the most value out of you for them to keep paying you each month for the work.

Your exact rant is a standard I have followed before and guess what, the company I worked for didn't care for it and made a lot of money, it made debugging and maintaining a lot easier for me and pretty much gave me work-life balance (about 6mo)

@Sid2006 I follow college standards. I know why they are important, and the trust I build is always enough to convince them to follow me. I don't work without trust. About managers: I don't see them. I don't believe they are important. To me, they don't exist. This is why we don't hire them.

I work with the business directly. I only care about the business and the users. If they insist this structure should be revisited, they don't understand my job and sabotage it. I don't tolerate this behavior.

However, I can empathize with people less fortunate than myself. But please, don't discredit college standards just because some managers manipulate people into doing it.

When the testcases only check for HTTP Status codes.

@kiki a little condescending to call me less fortunate..but alright.

@Sid2006 sorry. I didn’t mean to call _you_ less fortunate. I meant other people that have to work with bad managers/terrible outsource companies, which frankly is a majority, even among devRant audience. The only reason I don’t have to deal with this BS is sheer luck, not skills.

@Sid2006 sorry to hear that you have to work with that shoddy codebase.

I worked with backend dev who said fuck this, I am gonna fix that shit and make it work right from now on and he did (he also retrospectivly fixed this on very large scale projects), all i had to do on the frontend is catch error on response and display it.

It is called error handling and its pretty standard thing to do on backend (the right way).

If you have that view on plain http errors, i am afraid to ask if you even validate data that is submitted to you - imagine that. Submit > 200 OK: {error:401}

Should I also handle the messages and have the whole http error dictionary on the frontend?

Bottom line is: error handling is backend part, CSS is frontend part. If you disagree, please send me styling in response because I am too busy dealing with 200 OK errors!

Also on SIMP view of sending 200 ok in order to see if the API is working is ridiculous.

Use the friggin postman/insomnia/paw for this kind of shit!

When it's okay for an API to not have a clue.

I once had WebService send me a header claiming it'll respond in "application/json;q=0.9, text/xml;q=0.8" because let's not be sure what we serve - keep them guessing!

@cprn man… quite unrelated, and I feel like a weirdo, but I can’t help but read your nickname as “C porn”. Are you by any chance a C programmer?

Well yes, but actually no

@kiki Indeed, I am. Also, I'm old as f*ck and back in a day programmers tended to shorten variable names by omitting vowels. Take a name "Cyprian", remove "y", "i" and "a" and you get "cprn". FIN. You can call me Cy if it helps you in any way.

@cprn to me, you've always been and you will always be c-porn

Dunno what the c refers to.

@electrineer C-porn: