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 <bobjolli...@gmail.com> wrote: > Hi > > On 9 November 2010 05:58, Jo Størset <stor...@gmail.com> 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~dhis2-devs >> More help : https://help.launchpad.net/ListHelp >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : dhis2-devs@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > -- Cheers, Knut Staring _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp