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
_________________________________________
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]
