No error messages in 200-299 statuses

[philsturgeon]

Make sure the response object for any 200-299 response code does not contain any of the following properties:

• errors
• error
• warnings
• warning

It should also not contain these:

• status: false
• status: "error"

If you can think of any other common error properties that would definitely be errors, feel free to bung them in too.

[savage-alex]

I saw this today

{
"failures":false,
"data":[

[janbrasna]

This one is interesting. We're using an API call to get status fields for various form inputs, 200 OK meaning all's good (session checks out, states match etc. and there is a non-empty response to show), yet there's errors content, flagging some user input elements not matching each other, with help hints to present for validation. Basically an intended outcome of the call.

While I understand the idea, does it always mean that any "error" or "fail" or "decline" negative values or fields mean the operation itself is not actually doing its expected job?

[philsturgeon]

Thanks for rasinging this, because the questsions you'are asking are exactly what the rule is meant to expose.

The operation is whatever the user is trying to do, and if there are failures in whatever they are trying to do then whatever they are trying to do has failed.

Errors are not just for server mistakes or JSON syntax errors. That would be subduing most of the purpose of most of the functionality in HTTP, treating it like a daft RPC pipe only able to say if the pipe is working.

Beyond that, returning errors on 200 means all monitoring software has to be specially trained to look for your errors or warnings or problems or didntgotoowellsorry custom JSON, which rules out all the benefits of using generic HTTP-based tooling.

Let's get this rule added, and point to this blog post when we do it. https://apisyouwonthate.com/blog/useful-api-errors-for-rest-graphql-and-grpc

[janbrasna]

Great. (Dumb RPC pipe is what I struggle with, day-to-day. Spot on!) — So I guess the short answer to my doubts about such cases is actually the intended outcome: the style lint tells me to think about it more broadly… and maybe get beyond the HTTP (=transport) meaning, think more about 422s and adopt own system of problem+json even for "business logic" outputs, where an error payload is the expected happy path of the endpoint. Sweet.