Open steve-chavez opened 4 years ago
The expectation was that canonical URIs were preferred, but realistically URL encoding URIs as query string arguments is ugly and counter to typical practice for systems that already have some equivalent concept of alternative profiles that can be chosen.
There are two things we need to consider: 1 - whether we should allow tokens in Accept-Profile values 2 - how to make the spec clearer whichever option we choose.
Lets hears pros and cons from people about allowing tokens in the Accept header.
(PS its no great drama for me in the implementation to allow it - so I'm agnostic, other than I feel there must be URIs for profiles accessible otherwise there is no interoperability benefit at the data level - and we are a Data Exchange WG :-) )
Hi @steve-chavez & @rob-metalinkage the Dataset Exchange WG has just split repositories for DCAT, ConnegP and so on so I've transferred this issue to the ConnegP repo from the DCAT one. Please continue all ConnegP work here!
@nicholascar Cool. Thank you.
@rob-metalinkage I would be in favor of allowing the token in the header. It makes the header easier to type and thus makes APIs easier to explore.
In the document it's mentioned that one of the reasons of qsa-uri is to allow human-actionable content negotiation. I'd like to add that API explorer tools(such as Postman, Insomnia, etc.), make modifying headers human-actionable as well. Setting headers is something that Open Data users and developers are used to when exploring APIs.
Regarding interoperability, I agree, I also intend to provide the token mappings.
(also pinging @RubenVerborgh and @hvdsomp as co-authors of the IETF draft)
But there isn't an example with a profile token in an Accept-Profile header.
When writing the current IETF draft specification of the headers Accept-Profile
and Content-Profile
my co-authors and I have attempted to minimise the coupling of URIs with other mechanisms of profile identification (cf. also the discussion on the use of "token" attributes in the Link
header). I personally am not very inclined to allow for profile tokens in the http headers. IMO that will be a source of confusion since different services might map the same profile URI to different tokens.
In https://www.w3.org/TR/dx-prof-conneg/#profileid it's mentioned that:
There is an example in https://www.w3.org/TR/dx-prof-conneg/#getresourcebyprofile on how to make a request with a token profile in the UR(with the
_profile
query param):But there isn't an example with a profile token in an
Accept-Profile
header.Would a request like the following be valid for profile negotiation?
(Granted that token mappings are provided as specified in https://www.w3.org/TR/dx-prof-conneg/#http-tokens)
I'm trying to implement content negotiation by profile on postgrest.org.
Would appreciate any clarification/guidance on this. Thank you.