I actually don't mind this approach too much, I had already realized that multiple posts would be required to keep caches in synch, see last week's design notes (copied from 2 previous non-discussions). My second proposal was intended as a way to do things with one post, by having everything go through the superclass.
Saptarshi's noting the difference between resources and representations was really key for me. We can get the availability of parent class fields we want by having a full representation that includes the full representations of the parent class. However, I think we need some additional representations to make things clearer for users (see RESTWS-225). I'm concerned about one-step creation of subclass resources. I'm pretty sure there's no other way to do it. What concerns me is that the notation for subclass resources seems like it ought to spread to subresources as well. That is, what we normally expect in our JSON for an object is a reference; what the notation for subclasses says is that we can replace the reference with JSON curly braces and define a parent class' values within them (including uuid, which is being set by subclass). So when we define a person, why shouldn't we be able to substitute for a name in the list of person_names a pair of curly braces and define the person_name? If we can, great; if we can't, can we make it work that way? Then what happens when you have a many-to-many relationship with a relationship class? Can we replace a reference in the list of related resources with curly braces and define it as well? This is going to be totally recursive, so needs to be done right. From: [email protected] [mailto:[email protected]] On Behalf Of Burke Mamlin Sent: Tuesday, April 17, 2012 9:38 PM To: [email protected] Subject: Re: [OPENMRS-DEV] REST WS and subclasses Darius, Did you mean to two posts, one to patient & the other to person? Both of yours were to the same resource. 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 person/abcd1234 { gender: 'M' } Cheers, -Burke On Tue, Apr 17, 2012 at 8:01 PM, Darius Jazayeri <[email protected]<mailto:[email protected]>> wrote: 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. ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list
