QUERY: Why should a server ever prefer direct or indirect responses?

[nicowilliams]

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.

[MikeBishop]

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.

[nicowilliams]

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.

[reschke]

@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.

[mnot]

Per discussion on #2897, this is orthogonal to QUERY -- it's applicable to other methods too.

[reschke]

(closing due to inactivity)