I would totally agree that this is by no means pressing for me. Nice to have, but Jo's suggestions curl will do that I need to accomplish.
On Wed, Nov 10, 2010 at 12:33 AM, Lars Helge Øverland <larshe...@gmail.com> wrote: > > > On Tue, Nov 9, 2010 at 6:58 AM, Jo Størset <stor...@gmail.com> wrote: >> >> Den 8. nov. 2010 kl. 23.43 skrev Lars Helge Øverland: >>> >>> >>> Required note: As long as we don't call it REST :) REST imples a >>> hypermedia-driven application, so let's stick to calling it what it would >>> probably be: a simple web api. >>> >> >> Hey be a bit more visionary:) I think this is a great thought. >> >> Ok, if you say so :) >> >> We are getting more and more requests from people who want to use their >> own presentation layer (Ifakara folks in Tanzania will "make a web-based >> query tool on top of dhis2", Uganda folks are integrating dhis2 with a CMS >> etc). I'm envisioning methods for: >> - getting all data elements/indicators with (a bit extended) DXF and HTML >> format responses with embedded links to URLs pointing to a method giving you >> the full details for each as HTML or PDF. >> - getting all indicators with DXF/HTML responses with links to URLs >> pointing to a PNG chart giving the aggregated vales for the 12 last months. >> - getting all report tables as DXF/HTML with links to URLs pointing to >> SDMX-HD/HTML/PDF/Excel representations of the table. >> - getting all orgunits for a given parent as DXF/HTML with links to URLs >> pointing to GIS PNG images, and so on... >> There you have your hypermedia-driven application that moves from one >> state to the next by examining and choosing from among the alternative state >> transitions in the current set of representations. >> This kind of stuff will give potential users an elegant way of integrating >> dhis2 data into whatever tool they prefer and avoid hacking into the >> database or fumbling with the source code. If don't want your users to >> leave, make it easy for them to do so:) >> >> I had hoped that the mobile case could serve as a starting point for >> exploration in this area, but basically the mobile use case makes more sense >> as a "custom protocol" as it is now, so it has ended up as little more than >> an introduction of jersey (which I still think is the right kind of tool for >> this). So, at a practical level, I think we should start by identifying a >> specific use case where we can explore how such an api might make sense, >> without too much custom requirements for how it should be built. >> Distilling your list above might be a good start to get a sense of how to >> model an "application level" model (but we should probably have some use >> cases for making changes through the api, as well). I would certainly be >> interested in working on this, but I do have other commitments and don't >> really know the domain well enough to get the modeling right by myself. You >> would of course have to get Bob onboard (I'm not sure what he's wasting his >> time on these days, but I'm guessing it has to do with excel :), and >> probably be prepared for some changes to the way we map metadata to xml :) >> One problem with the hypermedia part is that there isn't really much >> mature tools that easily support this kind of api building. With jax-rs we >> have basically gotten a better alternative to servlets, but still the way to >> build decent linkable representations and mapping to standardized content >> types haven't really settled down into solid best practices. And with the >> amount of time it has taken for the rest community to come up with this kind >> of tool support, I'm not really sure it will materialize anytime soon. There >> are people building more innovative solutions out there, but those tools >> then are more bleeding edge or move into too different technologies from our >> current stack. >> There are also some difficult "ground rules" we have to make the right >> trade off for, if we want to give this a go. We have to make a rough cut as >> to what makes sense to target for such a web interface versus more >> batch-oriented import/export and low-level interfaces for performance. We >> have to make a decent 80/20 trade off for what would be the important use >> cases to model support for in this way. And we need to have a sense of how >> much weight we want to put into supporting old-school soap stuff (I know Ime >> has a little requirement for some support there, but not sure how many >> others are still subscribing to that way of modeling apis). >> Basically, I think it is a difficult challenge to both support larger >> import/export structures (where size is a main concern) and more fine >> grained representations (where it is more about finding the right >> granularity representations and integrating links in a natural way). I'm not >> sure how easy it is to model these two use cases with the same set of >> document structures. > > All this sounds good. > I have no real experience of creating REST apps so take this with a grain of > salt but I have been dabbling a bit with Spring MVC and its REST support > lately. XML representations can be achieved simply by including a > org.springframework.oxm.jaxb.Jaxb2Marshaller in the context and adding > spring-oxm to the classpath. JSON representations can be achieved by > including Jackson on the classpath through the MappingJacksonJsonView. > Creating generic Excel, PDF, JasperReports and atom/rss representations are > of course hard to do but support classes for writing application-specific > views for all these are available: > http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/servlet/view/document/package-summary.html > http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/servlet/view/jasperreports/ > http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/web/servlet/view/feed/ > Mapping to content types/content negotiation happens by looking at 1. the > "file extension" 2. the Accept header 3. a "format" request parameter. > Something to consider but for later, lets get the more pressing issues out > of the way first :) > Lars > > > -- Jason P. Pickering email: jason.p.picker...@gmail.com tel:+260968395190 _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
