We did not get to discuss this at last week´s design meeting and will try again today.
The underlying issue is that a subclass needs its own resource to access its class-specific data, while the superclass resource needs to exist in order to get all its members regardless of subclass. The best existing example of this is Order as a superclass and DrugOrder as a subclass, with other subclasses (e.g. LabOrder, RadiologyOrder) on the way. Details are below. If anybody has any idea how they would like subclasses to be represented, or particular use cases they would like respected, they are welcome to respond here or participate in the design meeting (which may take place at other than the usual time, keep an eye out here). -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Friedman, Roger (CDC/CGH/DGHA) (CTR) Sent: Wednesday, February 29, 2012 1:23 PM To: [email protected] Subject: [OPENMRS-DEV] FW: REST and subclasses Sorry for the last-minuteness, but at this afternoon's design meeting I would like to discuss how subclasses would be represented in REST. The general requirements are that the subclass be definable in a module, the superclass be listable, the subclass be listable, and the subclass-specific data be accessible. The constraint is the need to have each object in one and only one place per Darius. I also take it as a given that we are sticking with our table-per-subclass mapping strategy. This is my thinking at this point: GET (1) The superclass is accessed by its resource name for core or module. (a) The superclass is immediately listable and searchable in our normal way. The superclass resource works normally, all its representations work. (2) The subclass is accessed by its resource name for core or module. (a) The superclass resource and the subclass resource should have the same uuid because we are now using them for hashcode and equals, and they are the same object regardless of how they are referenced. For the subclass object to remain an OpenMRS object, we probably have to set the uuid in the constructor and have a dummy setuuid. (b) There would be no problem with listing and searching because the subclass resource would create an HQL criteria query for the subclass. POST (1) Without a UUID, the class being posted is the superclass or subclass which is created. The client is responsible for doing a POST on the superclass if there is any possibility of the superclass being cached. (2) With a UUID, fields in the superclass can be updated by posting to the superclass. The client is responsible for doing a POST on the subclass if there is any possibility of the subclass being cached. (3) With a UUID, fields in both the superclass and the subclass can updated by posting to the subclass. The client is responsible for doing a POST on the superclass if there is any possibility of the superclass being cached. (4) To assist in the multiple posts, attempts to reference fields which don't exist for the current object should be ignored, not flagged as an error. DELETE: (1) Deletes can be sent to either the superclass or the subclass. The client is responsible for doing a DELETE on the other class if there is any possibility of its being cached.
