Initial minimal REST API
Resource EHR
...
| Method | URL | Parameters | Description | 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 |
| POST | /q/{query-language} | Stores query, generates 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 form q/{QUERY_LANGUAGE}/ (examplesexamples: /q/AQL/, /q/AQL2/, /q/AQLinXQuery/) | |
| 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 |
...