Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

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

Projects

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 37 Next »

This project is assigned to the OpenMRS 1.9 release milestone

Background

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.

Design

A single OpenMRS module to support the core web service needs.  This module should contain both REST and SOAP options.

SOAP Style

  • Annotations to generate web services

Gliffy Macro Error

Cannot find a diagram with these parameters:

  • Name: Webservices DTO
  • Version: 1

Encounter DTO

  • uuid
  • datetime
  • encounter type (required)
    • required: uuid or name
  • location (optional)
    • required: uuid or name
  • patient (required)
    • required: uuid or identifier
    • optional: names
  • provider (required)
    • required: uuid
    • optional: identifier, names
  • observations (optional)
    • required: datetime, question concept uuid, answer (e.g., string, number, concept uuid, ...)
  • forms (optional)
    • required: uuid
    • optional: form name
  • orders (optional)

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 convert the data to DTOs from our module.  These DTOs may inform how we transform our API in the future though.

Conventions

  • Web services will need methods that allow for a list of desired properties to be defined at the time of getting an object to determine which "optional" properties are realized in the objects returned.
// something like this:
ws.getPatient(123) // default
ws.getPatient(123, [includeProperties: ["preferredName", "birthdate", "gender"]])
  • No cascading saves -- i.e., properties of objects that are sets are read-only and will require separate method(s) to modify them.
//we should support something like this
ws.addPersonName([patientId: 123, given: "Darius", family: "Jazayeri" ]);

// this will not work
def p = ws.getPatient(123)
p.names << ?[given: "Darius", family: "Jazayeri"]
ws.savePatient(p)

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 web services... we will write the web services as an independent activity, hoping that they inform the further maintenance and redevelopment of the existing API.
  2. We will use CXF as the framework.
    1. See Webservices.cxf Module for the documentation start for that module
  3. Both OAuth and ws-security are supported

Assigned Developer(s)

~sunbiz

Interested Parties and Mentors

~bwolfe (mentor)

See Also

  • No labels