Initial minimal REST API
...
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 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 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 |
Resource CONTRIBUTION
Method | URL | Parameters | Description | Model | Notes | |||||
---|---|---|---|---|---|---|---|---|---|---|
POST | /contribution | Atomically commits a set of changes (composition creates, updates or deletes). |
| This call might also be under /composition resource. | ||||||
Implementation levels (suggestion)
...