dhis2-users team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On Tue, Nov 9, 2010 at 6:58 AM, Jo Størset <storset@xxxxxxxxx> 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