Profile negotiation: list profiles with the OPTIONS method

[steve-chavez]

I'd like to implement the list profiles operation with the OPTIONS method in postgrest.org. I want to know if this approach could be considered in the spec or if there's something fundamentally wrong with it. The advantages of OPTIONS over the GET/HEAD forms would be:

• The response would already include the media types accepted by the resource(in the Accept header). There would be no need to add this information in the Link URIs.
• Reduces the HTTP chatter. When doing GET/HEAD the Link: <uri1>, <uri2>.. is not usually needed.
• Removes the need for supporting a reserved query param(_profile=all).

The way I see it, it also goes more in line with usual responses that contain the other Accept-* headers. Here's how an example OPTIONS would look like:

OPTIONS /resources/a/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Profile:
  <http://example.org/profiles/marc21-loc>;
          rel="canonical";
          token="loc",
  <http://schema.igsn.org/description/1.0>;
          rel="alternate";
          token="igsn-r1"

My main doubt here is the Accept-Profile header response. Would that be allowed according to the spec?

Any guidance on this would be much appreciated. Thank you.

[rob-metalinkage]

The use of OPTIONS was part of the original proposal - but feedback suggested we revisit this and it was dropped: w3c/dxwg#510

At this stage we'd probably need a detailed justification for the feasibility and superiority of using this approach to re-open this matter. Please review this.

The issue of HTTP chatter is a separate issue - I am wondering if link headers should only be provided if the specific conneg ALTR profile is requested - and if you only want the headers ask for HEAD, and if you want some other serialisation ask for it explicitly with a Content-type ? I have posted this as a separate issue: #19