search

sdmx-twg / sdmx-rest

This repository is used for maintaining the SDMX RESTful web services specification.
111 stars 24 forks source link

027-Clarity-Behaviour in case of mixed semantically valid and invalid requests #84

Closed dosse closed 3 years ago

dosse commented 5 years ago

How should the SDMX server respond when the request contains both valid and invalid SDMX (identifiable) artefact IDs?

Examples ('A' is a valid ID, 'AA' is not a valid ID):

Should the server ignore the semantically invalid IDs and return only the resources for the valid IDs, or should the server refuse to serve the whole request by returning an 422 error?

egreising commented 5 years ago

Considering that the SDMX IM is consistent and there are tools to discover the valid artefacts, returning a client error code 422 and not processing the request makes sense for the "structure request" use case. Nevertheless, I have a doubt: is it valid to use "OR" (+) for the ids of artefacts to be retrieved? I have never seen it before. And if it is ok, how does the version apply to each of the ids?

On the other hand, in the "data request" use case, A and AA are not artefacts but dimension (key) values, so the user has no means of knowing in advance if there is or there is not data for these keys, so the query should return those cases that match one of the keys. An possibility could be to return a status code different than 200 to indicate the "partial" result (might it be 206?)

Another matter of discussion could be what happens if the dimension is enumerated and the key value specified is invalid (is not in the code list). The NSIWS does not control it so far.

dosse commented 5 years ago

There are probably 2 general behavioural modes for data retrieval: "strict" and "loose"

# Situation Strict mode result Loose mode result
1 All codes are valid and we have matching data 200 OK 200 OK
2 All codes are valid but we do not have matching data 204 No Content 204 No Content
3 All codes are valid and we have a partial match (i.e. data exists for some of the codes only) 200 OK 200 OK
4 Only some of the codes are valid and we have data for these 207 Multi-Status (200 OK + 422 Unprocessable Entity) 200 OK
5 Only some of the codes are valid but we don’t have data for the valid code 207 Multi-Status (204 No Content + 422 Unprocessable Entity) 204 No Content
6 Only some of the codes are valid and we have a partial match for those (i.e. data exists for some of the valid codes only) 207 Multi-Status (200 OK + 422 Unprocessable Entity) 200 OK
7 All supplied codes are invalid 422 Unprocessable Entity 204 No Content

Instead of the current "404 Not Found" standard error when no data are available for the requested valid codes, the status code "204 No Content" is proposed here because getting no data should not be considered an error but just an “empty but still healthy state”.