[rrd-developers] REST interface

[Tobias Oetiker]

Hi Thorsten,

Yesterday Thorsten von Eicken wrote:

> Well, if you open the discussion... I'd love to see the following:
>  - RRDTool sans rrdgraph at the bottom layer for managing the data storage
>  - An HTTP/REST style service that provides remote access to the data store
> using semantics that are relatively independent of the rrd details (at least
> for store/fetch requests, create can have a pile of specific args, for
> example)
>  - An RRD graph library that has a pluggable back-end to fetch the data into
> which one can easily plug various storage systems, such as local RRD store,
> remote RRD store, or a different store altogether.

> I believe the current RRDTool is not that far from the above architecture, but
> it's not there. Having an HTTP based service on top of the data layer would
> allow for a lot of flexibility. Like it or not, HTTP has become the standard
> plumbing, at least in my world. Think of passing the requests through a load
> balancer to spread the storage across multiple store servers. Or using HTTPS
> for security. I believe in the end the real bottleneck will remain at the disk
> level and the HTTP overhead can be accommodated.
>
> Having the graphing be more decoupled from the storage is something that has
> been requested many times over, I believe.

I see too chalanges here:

* defining 'semantics that are relatively independent of the rrd details

* there are many (!) people and tools relying on the present
  interfaces

if you are interested in working in that direction, I would suggest
you create a prototype for the webinterface using perl with fastcgi
this should give you a good platform to write a REST interface for
all apart from the graph / fetch separation ...

cheers
tobi


-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900