http-extensions
http-extensions copied to clipboard
Another approach to QUERY
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...
I don't think that you want to REQUIRE that implementations treat it that way, but a suggestion that they could might help.
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.
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!
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).
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?
IETF 120 meeting feedback: the clash of two potential query parts probably makes this tricky.