Another approach to QUERY

[mnot]

Reading the remaining issues on QUERY, I'm starting to wonder if it would help to define it as a transformation on a GET request -- i.e., the body on QUERY becomes the query string on a GET URI, with the transformation governed by the media type on the QUERY.

That would clarify things like caching, identity, and conditional requests.

Just thinking out loud...

[martinthomson]

I don't think that you want to REQUIRE that implementations treat it that way, but a suggestion that they could might help.

[mnot]

Oh yes, this wouldn't necessarily be reflected on the wire or internally in implementations -- it's just how we talk about it / specify it.

[asbjornu]

That's sort of how I've thought about it all along, so I haven't really considered the option of having another perspective. But now that you bring it up, I can see how being more explicit about this correlation in the spec might be helpful. Thumbs up!

[reschke]

This sounds interesting.

However, it would conflict with the case where the target URI of the QUERY request already contains a query part (I don't believe it's a common use case, but it would still be a weird conflict).

[asbjornu]

However, it would conflict with the case where the target URI of the QUERY request already contains a query part (I don't believe it's a common use case, but it would still be a weird conflict).

Good point. Perhaps we could declare that to be a request error where 400 Bad Request, 422 Unprocessable Entity, or similar, is a warranted response?