Should I Aggregate Web API Errors?

Question

The Situation

We are writing a REST API that performs validation up-front. The code is written such that it tries to find as many errors as possible. However, each error might correspond to a different HTTP status code. Additionally, the client (the HTML) doesn't have a convenient way to parse/display the errors.

The Question

Is it better to just throw as soon as the first error occurs? Or should we do our best to aggregate the errors somehow? By the way, there is no requirement to try to handle as many as possible at once.

I am not looking for an opinion. I was curious if there was a standard practice in REST.

Why It Matters

The current code is really complex. Some validation can only be run if other pieces are valid. So there is this explicit dependency between tests. It is complex enough that it warrants using a 3rd-party library. But I would rather just eliminate the cause of the complexity if I am going to spend time on it.

Answer 1

I think your question is a bit opaque because there are different kinds of errors.

Connection/authentication/location errors

One part (which you handle most of the time upfront) if errors like: 404 not found, 401 unauthorised etc. Those are most of the time breaking and returned directly.

Redirects and other locations

Also things like 302 moved permanently may be covered before real data processing.

Content of message errors

If all of this is satisfied you get to the real content of the message:

Example: You have errors in the sent in data: 422 unprocessable entity (from webdav standard). For that you might need to start real processing. Reading, parsing the message. Validating it's contents etc.

Only for that last part we use aggregated errors, because we say the message is invalid and we want to be clear about: "Ok it's wrong, so what is wrong with it?"

For example see: https://stackoverflow.com/questions/15310649/should-http-status-be-used-in-restful-error-responses which covers that part.

Conclusion

So generally: We do not combine the basic errors, we send only one and try to handle this in order of the specification. So don't combine: 401 not authenticated with 302 moved permanently. It would not make sense. The client gets 401 unauthenticated and that's it. If it fixes that it gets the 302 moved permanently.

For the content we send a list (in json for example) with the wrong data sent in and what is wrong with it.

Answer 2

Aggregating errors can become horribly complex. Not only do you have the complexity of identifying what has gone wrong, you need to identify how and branch off a new behaviour to inform the user of the specific error. In addition, you also need some behaviour to detect that an error has occured, and that it must begin aggregating and feeding back errors instead of resuming normal procedures.

One solution would be to aggregate errors found, then simply inform users of what is considered valid input data. In the example of username and password, if both were incorrect, most websites would aggregate the two failing fields, then simply display a static output message for both. E.g:

Username must begin with blah blah, be blah characters long and not contains special characters.

Password must be longer than blah characters long and contain one blah, one blah and one blah.

Second solution would be to simply feed back the first error you get, and let the user retry submission of data, to find more errors.

Advantages of solution one: User will probably get enhanced experienced due to the aggregate of feedback, and is also probably smart enough to be capable of making the input valid from the messages received.

Advantages of solution two: Feedback will be quicker, but will only return one error. User will need to resubmit to gather more feedback which may in turn become frustrating. However, it will also be easier to implement, and in the same vein, the user should get there eventually.