REST API contract for resources having attributes

Development
5

The intent of *_attributes tables in the OpenMRS data model was to allow for local extensibility of the model. If, for example, your implementation needed a boolean concept.offline attribute that the community didn’t include in the data model, you could have it, almost as if you had convinced the community to ALTER TABLE concept ADD COLUMN offline boolean.

GET: /openmrs/ws/rest/v1/conept/8c92f9c4-a31a-4569-9f19-3ebbb6f8fa2b?v=full

{
  "uuid": "8c92f9c4-a31a-4569-9f19-3ebbb6f8fa2b",
  "display": "Diarrhea",
  "name": { "display": "Diarrhea", ... },
  ...,
  "attributes": [
    {
      "display": "offline: true",
      "uuid": "1a66b9e7-bcf3-4f78-b7da-9968e14dec4f",
      "attributeType": {
        "uuid": "e2d847ea-7620-4d12-a896-b4b395e1addf",
        "display": "offline",
        ...
      },
      "value": true,
      "voided": false,
      ...
    },
    ...
  ],
 ...
}

would become:

{
  "uuid": "8c92f9c4-a31a-4569-9f19-3ebbb6f8fa2b",
  "display": "Diarrhea",
  "name": { "display": "Diarrhea", ... },
  ...,
  "offline": true,
 ...
}

The contract would be the existence of the core (what comes out of the box) properties for concept. Local attributes (like concept.offline) would be additional properties used locally – i.e., they can only add to the core model. You don’t need the additional metadata explaining offline’s datatype (just like you don’t need additional metadata explaining concept.description is a string).

The difference between the current approach:

if (myConcept.attribute.find(function(it) {return it.attributeType.uuid == 'e2d847ea-7620-4d12-a896-b4b395e1addf';}).value) {
  // concept is offline
}

and treating attributes as attributes:

if (myConcept.offline) {
  // concept is offline
}