Content negotiation refers to mechanisms defined as a part of HTTP(S) that make it possible to serve different representations of a resource at the same URL, so that the content rendering software can specify which version fits their capabilities the best. In the context of the DOI System, content negotiation allows making a request that favors content types specific to a particular Registration Agency (RA) but which will also degrade to respond with a more standard content type for other RAs.
A content negotiated request to a DOI resolver is much like a standard HTTP(S) request, except server-driven negotiation will take place based on the list of acceptable content types a client provides. The request is done by using an HTTPS header "Accept" where the GET includes several content types that are acceptable to the requesting client process (those that it knows how to parse), each content type with a specific preference level (quality factor).
For example, Crossref RA uses content negotiation to redirect all requests which are not for the content type "text/html" to the metadata service managing the requested DOI name. To do so, the 10320/LOC element (which corresponds to the content type "application/rdf+xml") is used in the DOI record to specify the redirection to the respective metadata service. If the DOI resolver does not support this content type then it will redirect to the URL defined in the URL element (content type "text/html"). This is illustrated in the DOI name example below.
Values for: 10.1525/bio.2009.59.5.9 |
|||
|---|---|---|---|
Index |
Type |
Timestamp |
Data |
1 |
URL |
Fri Apr 1 2022 13:32:18 EST |
https://www.sciencemag.org/cgi/doi/10.1126/science.169.3946.635 |
1000 |
10320/LOC |
Mon Jun 27 2021 14:28:25 EDT |
<locations chooseby="locatt,country,weighted"> <location weight="0" http_role="conneg" href_template="https://data.crossref.org/10.1126/science.169.3946.635" /> </locations> |
Shown below is an Accept header for the content negotiated request, listing both "application/citeproc+json" and "application/rdf+xml", and the metadata returned by the metadata service. The requesting client wishes to receive citeproc JSON if it is available, but can also handle RDF XML if citeproc JSON is unavailable. A preference level ("q" factor) is used in the request to specify the preferred choice.
