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 representation*s. > > 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
_______________________________________________ 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