httpwg
QUERY: Why should a server ever prefer direct or indirect responses?
For that matter, if a user-agent could request a preference or requirement for direct vs. indirect responses, why should it prefer one or the other? That is, what guidance can the I-D give for when to use direct responses and when to use indirect responses?
Indirect responses have the benefit of allowing the user-agent to get a URI for its query without executing the query, and then also any subsequent GET of that URI will be cacheable as usual. Whereas direct responses mean executing the query immediately.
I don't think you can guarantee that the query wasn't executed simply because the response was indirect. You've gotten a URL that identifies where the results can be retrieved. Caching is the primary reason why, as using the response to a QUERY request to satisfy a subsequent GET request can have additional complexity. At the cost of a round-trip, you have something whose cache semantics are easier to reason about.
Certainly knowing a URI for the query/response would be handy for a cache, thus the need for Location:/Content-Location:, but that doesn't require a second round trip. I encourage you to write some text about why the server should prefer an indirect response. One possibility is to allow the user-agent to get a URI for the query and/or for one response to it without first executing the query -- the server could delay execution till the GET in the follow-up request, and that seems like a reasonable thing to do.
In a way an indirect flow allows the user-agent to "normalize" queries by obtaining URIs for them. This is why I think another new method, or request headers to influence the response's directness would be useful.
@nicowilliams - could you elaborate why
the server could delay execution till the GET in the follow-up request, and that seems like a reasonable thing to do.
would be useful for the server?
My preference is not to add new protocol elements unless it is crystal clear that they are useful.
Per discussion on #2897, this is orthogonal to QUERY -- it's applicable to other methods too.
