dhis2-devs team mailing list archive

[Jo Størset <storset@xxxxxxxxx>]

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.

Jo