Thanks Erik, I have not given much thought to a REST-full design, and once I feel that the functionality is worth putting into production mode, I'll certainly use your suggestions. I won't write comments inline to make it easier to follow :)
The idea is certainly to allow everyone (including myself) have access to key ADL 1.5 related functionality, and ADL workbench offers a lot of that. I've done the AOM first, since that is my #1 personal requirement. I've done very little RM, almost none, but I'll be extending this to RM too. I'd really like to have a few other references for comparison. Tom already has some xml output, and he'll modify that so that it'll validate via published schemas (or fail :) ) If you put your work online, that'd be another useful reference, I think having a few XML focused projects, especially in the form of web services would help a lot to collaborate on a more or less standard ITS. I'll talk to Tom about your suggestion regarding OPT, from my point of view, it does not sound like much work. I have actually completed only 30-40% ish of the total code I'd have to write, I am only doing Eiffel to Java with AOM. The full scope is bi directional AOM + RM. Good news is, it is not really intellectually a big challange now, since I've got the design working. Bad news is, it is a large piece of very boring code to write. The Eiffel code has been under Eiffel SVN branch for a while, I'll update that in a few days, and I'll also upload the code of the web service and simple web app under Opereffa's svn server. If you're curious about how this works, you can take a look at the code. Thanks for the kind feedback, and I look forward to working more on this. Best Regards Seref On Tue, Nov 15, 2011 at 10:19 PM, Erik Sundvall <erik.sundvall at liu.se>wrote: > Hi! > > On Tue, Nov 15, 2011 at 10:45, Seref Arikan > <serefarikan at kurumsalteknoloji.com> wrote: > > The web service exposes the archetype parser functionality of Thomas > Beale's > > Eiffel code base with XML and JSON output. > > Very nice work! Does this mean that it will be easy to keep it up to > date with the functionality of ADL 1.5 workbench? > > On Tue, Nov 15, 2011 at 20:39, Thomas Beale > <thomas.beale at oceaninformatics.com> wrote: > > for those interested in JSON, I will have a JSON outputter in the ADL 1.5 > > workbench in a few days > ... > > I will put a small rule-base in allowing some > > variant forms to be generated. If anyone has specific requests, let me > know. > > Some REST/HTTP/URI related thoughts below: > > On Tue, Nov 15, 2011 at 10:45, Seref Arikan > <serefarikan at kurumsalteknoloji.com> wrote: > > > http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypeslist > > You might want to swap at least the "resteasy" part of the URI to > something not bound to a specific product before finalizing the > interface. > > > > http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetype?archetypeName=openEHR-EHR-CLUSTER.case_identification.v1 > > returns the XML output. Simply changing the URLS to > ... > > > http://opereffa.chime.ucl.ac.uk/bosphorus/resteasy/openehr/getarchetypejson > > allows access to JSON output. > > Having different paths in the URIs for the same "resource" (same > archetype in this case) actually goes against some REST principles. > XML and JSON are just different "representations" of the same > "resource" > > See details regarding "resource" and "representation" in the HTTP 1.1 > spec http://www.w3.org/Protocols/rfc2616/rfc2616.html or Fieldings > dissertation http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm > > The HTTP protocol can handle the media-type negotiation depending on > the capabilities and preferences that the client sends in the HTTP > headers. When later adding a representation with another mediatype > (e.g. YAML or protobuf) you won't need to extend the URI space (and a > lot of client code can be reused). > > Of course you might want to override the HTTP negotiation in some > cases, but then I'd recommend to use a generic "media" URI query > parameter with values being media types > (http://en.wikipedia.org/wiki/Internet_media_type). If you also want > "pretty-printing" to be a selectable option (as Bosphorus seems to > provide) the resulting URI might look something like > > .../getarchetype?media=application/json&archetypeName=openEHR-EHR-CLUSTER.case_identification.v1&prettyPrint=true > > Having an access route with URIs like this might also be nice in the > future: > .../archetype/openEHR-EHR-CLUSTER.case_identification.v1/ > (Exposes the resources nicely and gives very clean URIs in listings etc) > > In LiU EEE we provide URIs to RM VERSION objects (e.g. COMPOSITIONs) > like this... > > http://hostname.domain.se/ehr:example-EHR-ID/129134f5-af94-4940-bea3-ad556d0efdb8::test2.eee.mi.imt.liu.se::1 > and depending on what your HTTP client asks for in the HTTP headers > different representations, like XML or HTML will be returned. If a > client wants to override e.g. preset browser settings they just append > a query string like ?media=text/html > > We aim to get an updated demo server online soon too and have been > focusing more on REST for the RM side of openEHR. Source code will be > published together with a paper. Perhaps we have avoided duplication > of work if you have focused on REST for AM and we mainly for RM :-) > > > In the near future, we are going to be extending the set of services, > and we > > would be glad to hear about your ideas for new web services in the > tooling > > space. > > A web service taking a Template file (and archetypes either from > repository or uploads) as input and generating an Operational Template > (OPT) as output in JSON or XML would be very nice contribution. > > There are a lot of magic output formats outlined in e.g. figure 3 of > > http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/aom1.5.pdf > that would be nice to be able produce online via http. > > Again, nice work! > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111115/99ec0efa/attachment.html>
