What's a bigger sin.

Returning a status code of 200 and then the message body saying "An Error Occurred"

or

Only performing data validation on the frontend.

Not firing you for asking questions like this

Second one!
First one might be warranted (well not exactly like that but there is a difference between transport and application) or just super annoying. Second one is dangerous.

@hjk101 agreed, the first one is a bad and annoying practice the second is a serious security error.

The first can be worked around by a client/user, the second cannot be solved by the user.

Asking a question with a period at the end of the sentence.

Don’t make me choose

First one could be used in a scenario where the api server and client is OK, but the API used by the API you used had given an error, it could give that as an error.

Or not, idk.

Oh, if I had to choose? All of the above.

Why not do data validations on front end side?

I would rather say among the above 2, the second one, but in indirect way.

Not doing validations on backend side, period.

Why are you even comparing a vulnerability to an API design error?

@Voxera I keep needing to put this example in:
'GET /api/v1/job/1234'
Here we are getting job details of job 1234. Getting the job details succeeded so it needs to return 200 OK. However if job 1234 itself failed the payload would be 'an error occurred'.

HTTP status codes are not meant to be application codes and are not reliable on without the app docs. There are conventions but that's it, no standard.

The first one will cost your reputation and time (and consequently money) to whoever is consuming that information. The second one will also cost your reputation but this time it also costs whatever happens if the validation is bypassed.

@gowtham-sai keyword only

@hjk101 convention is better than anarchy is what I'm going for.

@hjk101 if your url had been /api/vi/job/1234/status

Then 200 would be that the job worked while you could use some 5xx to indicate the error of the job.

So its very much up to how you design the api.

And any error in the api should have different 5xx or 4xx messages.

That way you could judge success just from the http status.

But it requires the api to be built for the purpose of doing that specific testing.

But it would also mean that it would be very easy to test for a successful job even on systems that do not have a mean to parse the payload.

Like a firewall that might need to change routing if job failes.

@Voxera with all due respect that is regarded as very bad design. If you would do a POST on the job endpoint or a PUT/DELETE in on the job/{id} endpoint and it fails during that request than than 5xx (or 4xx) would be in order. A 5xx on any GET endpoint can never have anything to do with the state of the application unless the state would make it impossible to retrieve the information e.g. fail the actual GET request.

I feel a GET on /api/v1/job/1234 should return the status (among other things). Not much other use for it. It is best practices to keep sub-resources to a minimum.

@Voxera sorry I was not really clear in the last comment. Your suggestion is the same issue as with returning an error response body and success status but reversed: you return an error status on a request that succeeded.

This may seem convenient for you and as I suggested breaks convention but might be documented as such.
Usually the consequences of 5xx are much more severe than a misguided 200.
For instance some clients do retry on some 5xx. Also 5xx failure rates are monitored. So if multiple consumers are interested in failed job 1234 and perhaps even do retries in your setup it would trigger an alert.

@hjk101 I don't understand why the api shouldn't return 200 when the api does his job: Return job x's details.

When it's 4XX, it should be user error like not authing or requesting a non-existent job.

When it's 5XX it better be a database error or something because otherwise I will come to the datacenter myself and punch the virtual machine.

IF A API DOES IT JOB AND GIVES ME 500, YOU BETTER BET THEY ARE EITHER PAYING FOR THERAPY OR I'M NOT USING THAT HELL.

@melezorus34 yes that is exactly what I'm saying!

first is a design issue while second is a security issue - and a design issue.