...
| Method | URL | Parameters | Description | API level | Notes | |
|---|---|---|---|---|---|---|
GET POST | /query
| aql | Execute an AQL | QL1 | GET has a max limit on the query length that will be too short for some queries. (Also if using GET make sure that the server sends proper caching headers.) Should we allow both POST and GET? Added post for querying to allow loooong queries HF: I think we should support POST only PP: we should support path-based queries also, not just AQL. E.g. GET /queries/execute Wiki Markup | { ehrId: ..., q: [ { archid:.., path:.. }, {archid:.., path:.. }, {archid:.., path:.. } ] } this This would get rm objects from certain archetype ids and paths, from the ehrId. See We use a similar structure in the EHRServer: https://cabolabs-ehrserver.rhcloud.com/ehr-0.3/query/show/2 (screen capture http://postimg.org/image/gso1jsr0x/) PP: we should add support for stored queries also, so queries can be stored on the server side, and executed by id + context parameters like date ranges, ehr uids, etc. |
| POST | /q/{query-language} | Generates a query-id and redirects to resulting resource (se rows below) | QL2 | (see http://www.biomedcentral.com/1472-6947/13/57) By default the query-id could be a SHA hash of the query itself (that way repeated identical queries do not need to be re-parsed/stored) If the http-server-log is used as the main source for audit-logging, then the query needs to be stored somewhere since the content of POST is usually not logged in http-logs (The stored query could be inspected using GET q/{query-language}/{query-id}/info/ ). Storing a query (could be an ad-hoc query) for logging purposes does not mean that it needs to be converted to a stored procedure in the database. Manual or automatic routines can be used for deciding when recurring queries (same hash) should be optimized/stored. If we want to support different query languages (or query language versions) we might want urls on the form q/{QUERY_LANGUAGE}/ (examples: /q/AQL/, /q/AQL2/, /q/AQLinXQuery/) HF: Is this an specification alternative to the above or will both be included in the specification? HF: Although I like the idea of the redirect approach, I have some reservation about how javascript clients will react to these redirections HF: Should AQL be assumed in a shortform of this? | ||
| GET | q/{query-language}/{query-id} | the dynamic parameters defined when query was stored | Executes named query (using dynamic parameters) | QL2 | ||
| GET | /ehr/{ehrId}/q/{query-language}/{query-id} | the dynamic parameters defined when query was stored | Executes stored query (using named parameters) | QL2 | Discussion: Do we want to allow the possibility to (optionally?) split URIs for single- and multi-patient queries like this (including EHR ID in the URI)? Single-patient queries may have simpler requirements regarding security and may be more efficiently implemented in certain distributed environments. See http://www.biomedcentral.com/1472-6947/13/57 HF: I think this is useful to indicate single-ehr queries from multi-ehr queries. This should also be specified in the original query POST. |
...