A tweaking of the ECoreDefinitions.xml format messed with my hope of an early night - but all ok just a few things have moved around. As this settles down I hope to be able to deal with new resource definitions without the need of any manual coding.
This involved getting some understanding of representing search parameters and also how to create a response format.
For each resource a list of search parameters is defined - for example Patient resource search parameters.
As a very basic set to play with have chosen a subset.
_id | The logical resource id associated with the resource (must be supported by all servers) | |
active | Whether the patient record is active | |
family | a portion of the family name of the patient | |
given | a portion of the given name of the patient |
This allows the search HTTP GET operation to be performed.
GET [service-url]/[resourcetype]/search(?parameters) (&format=mimeType) GET [service-url]/[resourcetype]/(?parameters) (&format=mimeType)
These parameters are used to query for matching results. The results are returned as a 'Bundle' in ATOM feed format. This format allows multiple resources found as query results to be returned. This response includes some meta-data around the result including last update, author, titles and descriptions for the feed and returned entries for each result resource instance.
Check out some example queries:
All patients | http://demo.oridashi.com.au:8190/patient | |
Inactive patients | http://demo.oridashi.com.au:8190/patient/search?active=false | |
Patients with family name starting in 'ab' and given name starting with 'be' | http://demo.oridashi.com.au:8190/patient/search?family=ab&given=be | |
Find a particular patient id | http://demo.oridashi.com.au:8190/patient/search?_id=36 |
An important part of returning results is to support maximum returned record count and also paging capability to allow navigation of results. That may well be the next topic....
PS: the Provider resource was also added - try: http://demo.oridashi.com.au:8190/provider/@3