[kortex]

I can't wait until this becomes a spec. I wrote a small middleware to cache sql and graphql queries and I implemented QUERY and Cache-Control. Worked great and saved a ton of bandwidth for developing and running reports, as I didn't have to worry about caching progress. I just reran the whole job. It was like <50 lines of python to pull it off.

[ta-run]

What I fail to understand is how the server interprets the query content/body; how does the server "apply" the "sql" query in the request to the resource? is there something similar to a gql resolver that you need to write?

[kortex]

It's agnostic, the QUERY verb has nothing to do with the actual implementation, or the content encoding. You can use any content encoding for your query body, and you can resolve it any way you see fit.

In mine, I was just caching raw sql queries, so it was literally just text/sql encoding, the query in the body, some metadata in headers, and a sqlalchemy engine to execute the query.

It's basically a way to get around the non-idempotency of POST and URI limitations of GET.

[ta-run]

Aha, got it. Thanks for the explanation.

So, the request content/body can have "non-sql-like" queries? can it be GraphQL? or even plain English? - of course, assuming that the server knows how to resolve the query.

[kortex]

Yep. This is valid

    QUERY /graphql
    Content-Type: text/graphql
    {too lazy to write valid gql}

so is this

    QUERY /elasticsearch
    Content-Type: application/json
    {"name": "alice"}

Even this

    QUERY /my-ai-image-gen
    Content-Type: text/plain
    Draw me a picture of a cat

It's entirely up to the software to decide how to handle the request.

[ta-run]

Great, thank you!

[linuxdude314]

I'd love to see JSON-RPC overhauled with this method. It's quite a pain to cache idempotent methods exposed over JSON-RPC as-is currently.