I think a more general way of describing your design principle is, “Only return information that will be useful to a client.” Clearly “Just return one error” might not be the exact right rule. Other than the forms example you mentioned, if you’re using http in your service-oriented architecture, and you’re sending a batch request, you might want to return errors for each item in the batch, so that you can choose how to handle each request separately.
I don’t think the JSON errors array is a map of exceptions (what JavaScript calls Error). I think it’s a list of issues, and for example, you should have one for each thing that the backend is complaining about (e.g. your point 2).
No point in doing multiple round-trips to the server if one will do.
No point in doing multiple round-trips to the server if one will do.
I guess that’s my point, in my experience clients are rarely prepared to handle multiple errors. Returning multiple errors doesn’t guarantee that you returned all errors, and may be dangerous on the server.
I think a more general way of describing your design principle is, “Only return information that will be useful to a client.” Clearly “Just return one error” might not be the exact right rule. Other than the forms example you mentioned, if you’re using http in your service-oriented architecture, and you’re sending a batch request, you might want to return errors for each item in the batch, so that you can choose how to handle each request separately.
I don’t think the JSON errors array is a map of exceptions (what JavaScript calls Error). I think it’s a list of issues, and for example, you should have one for each thing that the backend is complaining about (e.g. your point 2).
No point in doing multiple round-trips to the server if one will do.
I guess that’s my point, in my experience clients are rarely prepared to handle multiple errors. Returning multiple errors doesn’t guarantee that you returned all errors, and may be dangerous on the server.