In OpenMRS Core orders are represented by the following classes:
Order is the parent class while the other two are child classes implementing specifics to drug and (lab) test orders.
Two possible design routes for a third-party module (such as REST Web Services) to expose resources for the child classes could be illustrated with the following sets of URLs:
- /api/order/drugorder and /api/order/testorder
- /api/order?t=drugorder and /api/order?t=testorder
In the first case, each class will implement its own
@Resource class. By implementing this method, a lot of the code is replicated as there is one parent who has most of the properties already. And changing in parent class ,we have to make changes to all the @Resource classes also. This would easier become complex after awhile.
In Second case, OpenMRS REST API provides a functionality for this using a single @Resource class for the parent and managing its child/other types using @SubClassHandler. Like in Order and DrugOrder case, this reduces a lot of work and complexity.
Sub Class Handler provides you the facility to add different child classes of single resource while handling all the complex work behind. You only need to provide annotation @SubClassHandler. For example, Order class has two child classes DrugOrder and TestOrder, but there is only one single @Resource class of OrderResource. The child classes have their @subclasshandler classes instead of separate resource.
In Order model, Rest Module has only used single @Resource for parent only. In @Resource class , developer has to only implement hasTypesDefined() to tell OpenMRS REST API that this has child classes too.
The Child classes of Order have annotated @SubClassHandler , extends BaseDelegatingSubclassHandler<parent, child> and implements DelegatingSubclassHandler<parent,child> .
This has resolved all the type and heritage issues and rest module take controls of all the rest.