1. What is the semantics of having values for query_parameters in the stored query definiton? What would be expected behavior when offset and fetch are added. I guess it would make more sense to just provide a plain AQL query as text, including the parameters in the query statement. I can only see consistency between query endpoints and definition endpoints as reasons to do it this way as described in the spec.
2. is it intentional that the path does not contain "definition" (v1/definition/query/...) like for the templates?
3. what is the expected behavior when there is a (stored) query with query_parameters but the client does not provide values for all parameters? In my opinon the server should give an error message that parameters cannot be replaced in a query - : I agree if any query ad-hoc or stored has variables in the query ($XXX) and no parameters are provided, it should result in a 4XX error.
4. Jake Smolka: I fail to see the specific use case of the If-None-Match header when POSTing a stored query. Why is it specified there?
I understand how If-Match works when checking for a previous version of a composition when updating it. But here I don't see how referencing via UUID makes sense, especially when there's also the qualified_query_name for referencing and the UUID contains no version information, because the version already is a path variable.
Also, from the client perspective, I don't see a semantical connection from UUID to specific query, so that saying "if this not already exists" makes sense. Am I completely off track here?
And as Birger just pointed out, the "list stored queries" endpoint additionally doesn't return UUIDs at all, too.
Sebastian Iancu I'm sorry, but I cannot recall now the exact reason we had that header and discussion around the subject. It was perhaps related to versioning of stored queries (i.e. updating existing queries), or to register (store) the query only if not-already-stored. Perhaps @erik.sundvall remembers a bit better?