My biggest concern is that it requires that consumers of the API know/learn our data model; however, since the person is presented as a property of the patient and gender as a property of the person (not the patient directly), it's about as good a solution as I can imagine.
-Burke On Tue, Apr 17, 2012 at 10:42 PM, Darius Jazayeri <[email protected]>wrote: > Yes, I meant what you said Burke. > > (Hopefully that was my only typo.) > > -Darius (by phone) > On Apr 17, 2012 6:48 PM, "Burke Mamlin" <[email protected]> wrote: > >> 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]>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<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ 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]
