Since a couple of months I have been resolving DOIs making use of content negotiation.
When making my requests, I set the HTTP accept headers according to this list. However, options (available MIME types) may vary depending on the RA of a DOI (Crossref, DataCite etc.). And sometimes I found a MIME type mentioned in the list for an RA not to be available when actually making the request.
Now I have read about reactive or agent-driven content negotiation.
When the client makes a request for a resource, the server may respond with a list of available representations of that resource the client can choose from (300 Multiple Choices).
Then depending on the available options from the list cited above, I request the preferred representation, e.g., application/rdf+xml.
I would prefer to get a list of available MIME types for a given DOI beforehand (HEAD request) and then request the preferred representation. Is there already an implementation for that kind of reactive content negotiation?
The alternative would be to send a list of (qualified) MIME types with each request regardless of the RA and let the server figure out which type, if any, matches best (server-driven).
I think each of the ways have their advantages and drawbacks. The reactive approach results in multiple requests for a single resource but gives the client more control.
Hello, thanks for this detailed explanation of how you use content negotiation, and how it might better accommodate your use case.
I’m not aware of an implementation for the kind of reactive content negotiation as you’ve described it, though we can certainly understand the value in it and would likely benefit from that type of feature internally.
While we don’t have concrete plans (and thus a timeline), we would like to rewrite our content negotiation service and will take your feedback into consideration when we do.
Until then, I would recommend focusing on the core representations common to all registration agencies as listed in the crosscite documentation you linked above.
I think one of the problems is that how the list of available representations could look like is left unspecified:
Unfortunately HTTP leaves the format of the list of representations and metadata along with selection mechanisms unspecified.
I actually came across this method of content negotiation when reading about FAIR metrics, i.e., how a computational agent would obtain structured metadata about a record provided a DOI. See this paper, especially page 7.
If you need early testers/adopters once you are working on this, just let me know.