Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »


OpenMRS has an explicit API which has not been cleanly or explicitly exposed through web services.  We have a REST module and SOAP-based module(s) where folks have done work in the area.  We need a clear and explicit strategy for supporting web services.


A single OpenMRS module to support the core web service needs.

Heavyweight vs. lightweight objects? This is similar to's approach. We could consider small & big versions objects OR consider having a standard object with the option to list additive properties (e.g., custom object).

Based on Canada's experience with WS, Returning a "summary" of objects in a list may lead to a chatty interaction.

Look at Google Charts.

Consider that we may want to support both publish & subscribe – i.e., OpenMRS may

SOAP Style

  • Annotations to generate web services

Do we want to use DTOs at the API level?

  • At this point, we can leave the Java objects with Hibernate magic (all object properties assumed to exist) and

Changes to the API

  • Eliminate the "magical save" -- i.e., editing an object in any context should not make/persist changes to the database.  This should *always* require a save method call.
  • Have an explicit approach for how "stubs" (e.g., new Concept(123)) can be used

Action Plan

  1. Web services will be developed as an augmentation to the existing API... that is, we will not rewrite the current API and then expose them as webservices... we will write the webservices as an independent activity, hoping that they inform the further maintenance and redevelopment of the existing API.

See Also

  • No labels