dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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
<larshelge@xxxxxxxxx> wrote:
>
>
> 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 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.pickering@xxxxxxxxx
tel:+260968395190