Error response for REST API - json

Question

Below is the error response that my API is returning to the client:
{
"statusCode": "400",
"errors": [
{
"errorCode": "50009",
"fieldName": "bookingDate",
"errorMsg": "Input bookingDate must lie in the bracket: 20 Jan - 27 Jan, 2018"
}
]
}
Client cannot show the errorMsg returned by the API in the UI, but it needs bracket information i.e. (20 Jan - 27 Jan, 2018) while forming some more meaning errorMsg. So, client has to extract bracket information from the API response.
But, this can break the client's functionality if the text of the errorMsg is changed.
So, to make client's life easy, I would like to change the error response slightly like this:
{
"statusCode": "400",
"errors": [
{
"errorCode": "50009",
"fieldName": "bookingDate",
"errorMsg": "Input bookingDate must lie in the bracket: 20 Jan - 27 Jan, 2018",
"startDate": "20 Jan 2018",
"endDate": "27 Jan 2018"
}
]
}
So, is it the right way to add startDate and endDate into the error response (just for the client's benefit) or is there any other better way?
Thanks in advance.

Answer 1

You are free whatever information you want to add to your error response. If you it's really useful to you, there is no reason not to. Facebook does so. On the other hand I would try to not bloat an error response.
A well designed and decoupled REST API implies most of the error reasons with the help of the standard definitions of the HTTP error codes, which still should be documented within the API documentation. Given this, a developer of a client is able to know the exact error only by parsing the error status.
This also means that a client developer needs to check whatever he can, straight away, without sending any request to the back end. For example if the given date range is valid.
Stating this, if a returning error code cannot be used to figure out the exact problem of the request, the design of the API interface might be not optimal.
Although as REST is only a concept, it's nearly impossible to implement a perfect RESTfull API, therefor there are always exceptions, IMHO.

Answer 2

Although this question tends to attract opinion-based answers, I will try to give some perhaps helpful hints.
Your API seems to validate user input. This input may be invalid for various reasons (e.g. no parseable date, date in the past etc.). This can never be reflected only via HTTP status codes and as such, returning an HTTP 400 and a validation error message, as you already do, is good practice.
This validation error message should be human-readable and it should be okay for the client to display it to the user. If a field name is included (as it is in your example), the client can even highlight the associated input field and display the error message next to it.
If the consumer of your API is not a UI, but some kind of automated service, then error related technical fields may fit the needs more. (And this is where opinions come into play: Many people say that the API should be agnostic of the consuming client types). But I think in your case, you should rather investigate why the client is unable to display the errorMsg - this should be the best and most flexible way to go to add additional validations in the future.