That's a 200 response.

Thanks, DevRant!

@Frederick Incorrect count.

Special chars like “—“ and emoji count as more than one on the backend, but not frontend.

@Root TIL JavaScript has this now:

(new TextEncoder().encode('foo')).length

Also, it looks like the only thing to distinguish one type of error from another is the error message. Which is … shit design.

What is wrong with sending 200 status codes with status: false ??

@Sid2006 So many things.

@Sid2006 what is NOT wrong about it?

There's thing called http status code, dude.

Believe it or not, but they make sense and are categorized, OMG.

(If it wasn't so depressing to answer that question)

@IntrusionCM @root @netikras stop talking to me like im a child, first of all.

Second, my question was kinda rhetorical. The design pattern may not be compliant to the standards, i get it. But I see nothing wrong with sending 200 status with status: false.

Because in the context of devrant comments feature, they are not handing out their API services to external agencies. If they did then they must follow the standard HTTP status codes.

But if the commenting feature stays within DevRant, I see nothing wrong with 200 status codes with status: false.

@Sid2006 Not treating you like a child/junior, or I would have explained several reasons why (in simple terms).

But really, why is it okay to not follow best practices if something is only used internally? I mean, sure, if only you are using it, and it doesn’t cause security concerns, I … guess? But branching on status code is no more difficult than branching on data in the response body. I don’t understand why so many devs actively want to do this and defend incorrect 200s.

The only status code I might agree with not using is 404, as it’s ambiguous. It can mean a requested record is not found, or the api endpoint itself is not yet implemented. I’ve worked with some … less than reliable devs who say they’ve finished and released endpoints they haven’t even started on yet. So, the 404 responses were confusing and wasted my time.

@Root there's also a 204, which means the 404 exception is not required

@Sid2006 I'm very sarcastic regarding that topic.

If one wants to be very specific, it is also a resource optimization.

All good clients require the body to be explicitly loaded and fetched.

The http status must be fetched immediately, along with few headers.

It might seem like an micro optimization, but it is an important one imho.

It becomes extremely nifty if you use async.

Cause you can then pass the request without body materialization directly to the "recipient".

E.g. pass it to the error handler, the storage layer.... .

Without the http status code, you would materialize the body, check the error code inside, decide if to store or to pass to the error handler, which then materializes the body again.

It is micro, but it's a nice optimization if the framework supports it.

@Frederick @netikras @root

Reminder that 4xx are *client* error codes.

https://developer.mozilla.org/en-US...

204 would mean that the request was successful, but the client shouldn't expect any content - as in body.

https://developer.mozilla.org/en-US...

As MDN says, it's mostly interesting for a fire and forget operation - alternatively an e.g. auto save operation.

404 is explicitly saying that the resource the **client** request doesn't exist.

Hence a 5xx is more proper if the server hasn't implemented the necessary function, but it exists.

After all, it's a fuckity on the server side to expose an unfinished / unusable API.

@IntrusionCM

get /products/26
=> 404 route/products/:id does not exist

get /products/26
=> 404 product 26 does not exist

A better example is s3 buckets. They return 404 for unauthorized access as a security measure against scraping, as well as when the server can’t find what you’re asking for.

@Root I meant the part of your comment that said "not implemented".

Look ups for non existing stuff is fine.

The 404 for unauthorized access is one of those things that I always found... Weird.

Like... You don't stop poking just cause someone said 404, neither does it stop scraping. I think it's a security by obscurity thing?

@IntrusionCM Ahh I can see the confusion. Yeah, the route wasn’t defined because the dev never started on the endpoint. It wasn’t implemented enough to have a NYI error.

@Root *sigh*

They never learn.

Yeah... I thought they returned 404 on purpose for not implemented API.

Not the first time I've seen such "reinterpretations".

The worst is when they freely interpret whatever fits by the header name in a http enumeration (the typical enum for code - reason).

406 - Not acceptable

As one example that made me especially angry, as the 406 is used to implement behaviour based on content negotiation.

These are headers that wrongly implemented can lead to a lot of interesting problems.

(guess how I found this out 😒)