The goal of this ticket is to address several issues:
- As we've implemented our controllers, Spring doesn't allow us to have two controllers bound to the same URL, so we can't have the core RESTWS module handle most GETs to .../concept and the RESTWS19ext module handle some specific queries on that URL.
- We don't have a mechanism to let the module define different versions of resources depending on the OpenMRS version
We need to significantly refactor the RESTWS module, approximately as follows:
- refactor RestServiceImpl so that its Map of resources is built up via Spring beans, and so we expose resources by name rather than by class.
- I should be able to ask for the "concept" resource and get back the correct resource (which might differ depending on what version of OpenMRS you are running, and what other modules are installed).
- modules need to be able to conditionally decide which resources to register. (I.e. we don't just want an @Autowired List<Resource>.)
- modules (including the core RESTWS one) that register these resources need to be able to specify their priority (e.g. so another module can override the core module's concept resource)
- rename all Resources in the core module to be XyzResource1_8
- the underscore is so we can handle XyzResource1_10, but I guess I don't care if it ends up being XyzResource110--we can deal with that when we release OpenMRS 11.0.
- move Resources from the 19ext module in as XyzResource1_9
- at module startup, conditionally load a different set of resources depending on what OpenMRS version is running
- Get rid of all the controllers, and instead have a single RestController that directs traffic. Something like:
Making these changes will not be backwards-compatible for modules that provide web services, so we should increase the version to 2.0 when we release this.
From the client side, you should not see any changes at all resulting from this refactoring.
Some notes at http://notes.openmrs.org/Design-Forum-2012-11-14