Problem description

Now all non-processable error are managed as 400 (badRequest) in this API, without properly informing the API consumer whether this is a syntactic error based on a invalid request format, or it is a semantic or functional error which implies that the required content is not accesible or procesable.

Possible evolution

Include specific 422 error for cases where the request is formally valid but cannot be processed due to content issues, e.g. bad combination of area size and time window, cell precision not supported...