Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Link correction

Initial minimal REST API

...

MethodURLParametersDescriptionNotes

GET

POST

/query

 

aqlExecute 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 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 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/)

GET

q/{query-language}/{query-id}

the dynamic parameters defined when query was storedExecutes 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

...

...