Hi All,
On tomorrow's design call one topic we will discuss is how to properly
represent inheritance and subclasses in a RESTful way. Fun and exciting
background discussion can be found on the ticket:
https://tickets.openmrs.org/browse/RESTWS-221. Call-in details are
here<https://tickets.openmrs.org/browse/RESTWS-221>
.
My proposal, generally supported by Saptarshi, and disliked by Roger, is
that we represent a subclass as basically the composition of a superclass
resource, and a subclass resource contains subclass-specific properties,
and a pointer to the superclass.
For example: GET patient/abcd1234 ->
{
identifiers: [ ... ], // this is the only Patient-specific property
links: [
{ rel: "self", uri: "patient/abcd1234" }
],
person: { // this is a pointer to the superclass
names: [ ... ],
gender: 'M',
// other properties on the Person superclass follow
links: [
{ rel: "self", uri: "person/abcd1234" }
]
}
}
This implies that if you want to modify a patient's gender *and* identifiers,
you have to do *two* POSTs.
For example:
POST patient/abcd1234 { identifiers: [ ... ] }
POST patient/abcd1234 { gender: 'M' }
You should be able to *create* a patient in a single POST, but not update
one that way.
At first this seems inconvenient, and unintuitive for someone who's used to
the OpenMRS Java API. The reason for this is that I think it's necessary to
support web-standard caching, which allows web service scalability.
Basically, imagine that someone may be running a reverse-proxy on their
server, which caches resources generated by the server and serves them up
to many web clients, relieving server load. In order for that reverse-proxy
cache to avoid serving up stale data, we cannot allow doing POST
patient/abc123 to modify the resource at person/abc123. (According to web
standards, if the cache sees a POST to patient/abc123, this invalidates
that specific cache entry, but all of this is invisible to the
server.) Thus my proposal.
I'm only moderately certain I'm approaching this right, so if you know or
suspect the right answer to this problem (especially if it's different from
my proposal), please reply and/or join us on the design call tomorrow!
-Darius
PS- The other topic we'll discuss on the call is Wyclif's proposal for a
module, that will allow us to reboot our implementation of orders and order
entry, such that we implement something better, and it runs on both old and
new versions of OpenMRS. All in all this will be an action-packed call.
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
