[OPENMRS-DEV] FW: REST and subclasses

[Friedman, Roger (CDC/CGH/DGHA) (CTR)]

    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.