Replace GET/POST with new HTTP QUERY RFC10008

[ebremer]

Replaces GET/POST in Search and Type Index with new HTTP QUERY

[jeswr]

As I understand RFC10008 is a proposed standard. I advise we either pause on merging this PR or mark the use of HTTP Query as "at risk" until the RFC is upgraded to an internet standard.

I am particularly concerned that clients will find this difficult to implement without support for QUERY built into libraries such as undici (the fetch implementation for node).

[ebremer]

HTTP/2 is a proposed standard as well. Just sayin' :-)

[jeswr]

proposed standard

This was my own misunderstanding of what maturity being a proposed standard implies. I stand down my request "to mark the use of HTTP Query as "at risk" until the RFC is upgraded to an internet standard."

I am particularly concerned that clients will find this difficult to implement without support for QUERY built into libraries such as undici (the fetch implementation for node).

nodejs/undici#5459 was just opened by the undici maintainers in response to nodejs/undici#5454. Given it was opened by the maintainers, this indicates the library intends to support this features soon (in fact will likely do so before this PR is merged).

[ebremer]

In the Eclipse Jetty world, jetty/jetty.project#15316 adds RFC10008 support

[gibsonf1]

Definitely a fan of moving to Query, but we should do it for the Type Index as well as that also needs to have additional things sent with it, such as labels etc to match on very large type indexes (optional based on implementation of course, but that will be the first thing TwinPod does is find types using text)

[ebremer]

@gibsonf1 this PR is for the Type Index

[ebremer]

In Tomcat apache/tomcat#1026

[TallTed]

HTTP/2 is a proposed standard as well.

And HTTP/1.1 has not been obsoleted, nor even updated.

(Well, apparently, this depends on where you look. RFC 9113 refers to RFC 9110, and RFC 9110 says that it obsoletes RFC 7231, but RFC 7231 does not say that it is obsoleted by RFC 9110 nor RFC 9113 nor any other! And here I thought that the IETF held themselves to a higher standard than other standards bodies. Their participants certainly present themselves as doing so, often enough!)

As I said during yesterday's call, client tools using HTTP (and related protocols) can always ask the server what methods it supports (see the OPTIONS method of HTTP/1.1, for instance). What happens next depends on the client — it might give up, or it might ask about another method or another resource, or it might use one of the methods the server has already indicated it supports.

I regret that I was not aware of RFC10008 until this week, so I did not make any comments on its evolution. Had I been aware, I would have suggested that there be further options available, like the server could indicate that it supports various query languages (e.g., SQL, SPARQL, GRAPHQL) in the payload other than whatever minimum is specified by RFC10008 as it stands.

[ebremer]

I regret that I was not aware of RFC10008 until this week, so I did not make any comments on its evolution. Had I been aware, I would have suggested that there be further options available, like the server could indicate that it supports various query languages (e.g., SQL, SPARQL, GRAPHQL) in the payload other than whatever minimum is specified by RFC10008 as it stands.

That capability is already in RFC 10008. There is no mandated minimum query language to extend past. QUERY standardizes a transport, not a query language, and the request's Content-Type defines the format. Advertising which formats a resource accepts is exactly what the Accept-Query response field is for:

Accept-Query: application/sparql-query, application/sql

Discoverable proactively (or via OPTIONS/Allow), or via a 415 that returns Accept-Query.