As a user, I want to clearly see which formats are accepted by the API when a 406 error is raised

[tloubrieu-jpl]

💪 Motivation

...so that if I use an unaccepted format I can switch to an accepted format close to what I want.

📖 Additional Details

See recommendation on https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406

⚖️ Acceptance Criteria

Given
When I perform
Then I expect

⚙️ Engineering Details

[jordanpadams]

@al-niessner let's take a look at this ticket while we wait on testing the pds4+xml response.

[al-niessner]

@jordanpadams @tloubrieu-jpl

I agree it would be nice to have the errors come back with more information and in the case of 406 with a list of acceptable formats. However, this is a bigger statement than this ticket supposes and needs-to/should be addressed prior to fixing just the 406 error -- in other words, the implied infrastructure needed for this ticket is beyond the scope of the ticket as written. While the log is updated (mostly) when errors are generated, the Exception is used to translate to URL errors, but no other Exception information (messages, names, stack trace, etc) are used in detailing the URL error.

I would like to have an expanded ticket that identifies what in the Exception message, if anything, should be passed to the URL error and thus that back to the caller. Also should that error content returned be HTML or JSON, the latter will not work well with browsers, or should a detection be done to support browsers different than cURL. Once all errors are being passed back with additional details for the end user, then this ticket can address whether or not the additive content to 406 should be expanded.

Another problem with matching MIME types is wildcards. The standard allows for wildcards like application/pds4* where we would then prioritize JSON over XML or something. Still, lets end user partially identify what they want/desire rather than spell it all out. Currently we do not support wildcards but can easily but not trivially -- all hooks are in place but algorithm could be expensive in terms of work effort.

Side note: the log already has the information you want for the 406 error.

[tloubrieu-jpl]

Hi @al-niessner , @jordanpadams

I fully agree with you on the error management in the API, I created the ticket #443

We can also create a ticket for the wildcard management in the Accept header although I would put it in the icebox to start with.

[al-niessner]

@tloubrieu-jpl @jordanpadams

If the Accept: is not known, the error comes back as JSON. Is that the desirement or do you want it in text/html because you expect the browser to be the main client?