...
Question: Is this appropriate? If so, what's the right terminology for this? If not, what alternate approach should we be taking?
Usually the " default " representation of a resource will include "ref"-sized versions of other resources. E.g. the default representation of a patient contains:, while the full representation includes "default"-sized versions of other resources. For example a patient would include
default | full |
|---|---|
{ |
...
{ |
A more relevant example of this is that an encounter might contain 100 observations. The default encounter representation would just include a displayable "weight = 70", whereas the full encounter representation would include full details about the "weight" question (e.g. that it's unit is "kg", its range is 0-250, etc).
...
We also have the idea of "sub-resources". For example a patient has identifiers. These sub-resources will not get a top-level uri, rather:
list all identifiers for the given patient | GET /ws/rest/patient/uuid/identifiers | |
list all identifiers for add an identifier to the given patient | POST /ws/rest/patient/uuid/identifiers | |
add an identifier to the given patient fetch/update/delete a specific identifier | GET/POST/DELETE /ws/rest/patient/uuid/identifiers/identifier-uuid | fetch/update/delete a specific identifier |
We'll lean towards making things top-level resources rather than sub-resources, for example:
...
We've tried to standardize the way we do CRUD via interfaces (Searchable, ( Creatable, Retrievable, Updatable, Deletable, Purgeable), and via a base class that helps reflect these interfaces onto our pre-web-service domain objects: DelegatingCrudResource.