On: The HTTP Query Method

[MuffinFlavored]

A simple query with a direct response:

    QUERY /contacts HTTP/1.1
    Host: example.org
    Content-Type: example/query
    Accept: text/csv
    
    select surname, givenname, email limit 10

Not quite full SQL (no JOIN or WHERE in any examples I see)

Hmm... as long as you handle authentication/authorization correctly, why is it bad?

It's a way to pluck certain JSON fields that were otherwise going to be returned? Kind of like one of the benefits of GraphQL? Will this catch on?

[cjpearson → MuffinFlavored]

I think it would be a good idea to remove these examples from the draft as it gives people the impression that this method is SQL-over-HTTP. A more typical body might be a JSON object with various filter criteria.

[SahAssar → MuffinFlavored]

The request body is just an example, this does not specify the query language, just the http method.

[cryptonector → MuffinFlavored]

The example uses a non-existent MIME type named `example/query` as the request's `Content-Type`. We don't know what the syntax and semantics of queries of `example/query` type are, and we don't need to know because this is just an example!

But the intent is clear that one could have `application/sql`, `application/sparql`, and many other MIME types for representations of queries, and if one where to use one of those then the request body should be valid when interpreted in the context of the request's `Content-Type`. Thus you absolutely could have the full power of SQL, if the server were to support it.

[pimlottc → MuffinFlavored]

The WHERE is implied by the endpoint (“contacts”)

[MuffinFlavored → pimlottc]

That would be the FROM in my opinion. WHERE would be ? filters, etc.

[pimlottc → MuffinFlavored]

Oops, what am I thinking, you’re right