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.
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
