Web api response with a 200 status code

{
error: ".......",
errorCode: "..."
}

Grinds my gears

Let's call it a successful error

You would strike twice and deal 100 damage in total.

Well. That’s the thing!

What if it did work, but there was a error that didn't stop the request from completing?

Or am I changing my API's to now include warnings with 300's?

@PonySlaystation "Happy little accidents. Let's put a little pipe here and send the exception to /dev/null. Have you ever piped an exception to /dev/null? It's okay. It'll be our little secret"

-Bob FoSS.

They successfully sent the error. what's the matter with you?

@ComputerToucher 😱😱😱😱

🤔

we actually have a client that _requires_ this, because they've got a reverse proxy filtering out all non-successful http-codes, because iT MiGhT lEaK DaTa tO An AtTaCkEr.

Failed successful, proceed as normal.
*cough* graphQL.

@lotd it’s the way it’s gonna be😀

"Task failed successfully"

It is actually not that uncommon. Most login api's will return 200 even when it is a failed login. This includes Google etc.

That's why I do it also on login, on other occasions I use Bad request though

This topic has passed DevRant quite a few times and there is both no official REST standard and very valid reason to do so. These are hyper text TRANSFER PROTOCOL errors not application error codes @aBrokenDonut provides a valid example. Sometimes the HTTP codes have a meaning in gateway/proxy.
Sometimes it's very valid application behaviour:
GET /jobs/12345
{
"error": "/bin/bash: file not found"
"errorCode": 1
}

Must send 200 as getting information about the job succeeded but the job itself encountered an application specific error. Is the job did not exist you should get a 404