dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

When we revive this discussion for 2.0.7, we may want to take a look
at what the Worldbank has done on data.worldbank.org.

Particularly for exposing their data and even offering a competition
to use their REST API to develop apps on top, including mobile ones:

http://data.worldbank.org/developers

Perhaps someone you know would even like to make 15k USD creating a cool WB app:
http://appsfordevelopment.challengepost.com/

If we adopt parts of their API, we may even be able to point people to
the WB apps for dissemination and visualization.

Knut

On Wed, Nov 10, 2010 at 12:13 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> 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
>>
>>
>
> _______________________________________________
> 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
>



-- 
Cheers,
Knut Staring