dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

On 9 November 2010 05:58, 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.

I think it's definitely possible (and highly desirable) to use the
same xml bindings for dhis entities for all use cases within dhis.
Larger structures are just compositions of the finer grained ones,
Having 3 different xml renditions of a dataelement structure in a
single application is not efficient.  So I would certainly like to see
a common set of jaxb bindings to an xml which we can all agree is
useful and which can be used for mobile, import/export and ajax
exchange (the 3 case I see now).

There is certainly a case for having stream based input through a
common import point as well as finer grained services.  What is
preventing this being done comfortably at this point is the fact that
we haven't yet resolved the problem of identifiers satisfactorily.  So
going outside the stream based import we are obliged to either put our
heads in the side regarding database ids or we have to take steps to
ensure that we have a very, very closed system.  Of course if we are
talking about the purity or otherwise of REST(ish) approaches this
question of URIs is absolutely fundamental.  Moreso than some of the
other concerns raised about how restful is restful.  Solving the
problem of interacting with 3rd party systems (finegrained, restful or
otherwise) still fundaentally comes down to solving the problem of
identification.

My own sense after having looked at the range of
uniqueness-based-on-name, vs database integer id, vs urn vs uuid ...
is that we probably need to resign ourself to the fact that integer
ids are just plain useful and efficient so we need to address two
problems of
(i)   stabilizing them (save explicitly, rasther than depend on auto sequences)
(ii)  quailfy them to give them global uniqueness outside of internal
scope ;  eg what is known to the world as
http://dhi2.org/ke/dataelement/id/4 is known internally as 4.
Composition of URI is just example.  Lots of politics around how this
uri is formed.  In fact I can even see a possible real world use for
the WHO indicator metadata repository here.

There are a couple of pressing needs for non-browser based interaction
with dhis.  One being the downloading of updates to aggregatedatavalue
tables for offline pivot table cache refresh.  Though rather than
place a requirement for web api to be functional first, I intend to
proceed with libcurl for now.

Regards
Bob

> Jo
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>