Open Stack

On 08/06/2012 06:02 PM, Doug Hellmann wrote:
> I've submitted a patch to implement a few of the queries for meter event
> data using the "project" filter. As you can see from the diff [1], there
> are now 16 separate routes pointing to the same simple function that
> calls the database backend. This smells bad, so I would like to propose
> changing the API to remove some of the duplication.
> 
> First, when asking for values about a given resource, there isn't any
> reason to specify the user or project because they won't change for a
> given resource. I don't think it's going to be useful to ask for a
> complete dump of all of the metering data for a user at one time, since
> the events will refer to different resources and meters. That eliminates
> several variations, so instead of 16 URLs listed in the current
> implementation, we have 3:
> 
> /users/<user>/<meter>
> /projects/<project>/<meter>
> /resource/<resource>/<meter>

I assume you mean:

/resources/<resource>/<meter>

> For the supported calculations, we would add "/duration" or "/volume" to
> the end of the above URLs. That's 2 sets of 3 more URLs, with each set
> pointing to a function to do that calculation for us.

OK.

> For /resources/<resource> the metadata for the resource is returned
> (including the list of meters reporting).
> 
> These forms:
> 
> /users/<user>
> /projects/<project>
> 
> return the list of resources owned by the user or project.

I think it would be better to do:

/users/<user>/resources
/projects/<project>/resources

Since you would be being explicit about the resource/document returned.

Further, you would limit the return to a single resource document like so:

/users/<user>/resources/<resource>

In the same vein, I think it would be better to have:

/users/<user>/meters/<meter>

instead of:

/users/<user>/<meter>

For the same reason: you are being explicit that a <meter> is a resource
of which a user has many, and you are selecting a specific meter
resource from the list of a user's meters.

> I'm not sure what to do with "source." It seems like a source should
> just tell us about the list of meters is provides, and then we should
> ask for the meter data in the usual way. So /sources/<source> returns a
> list of meter names, and we use /resources/<resource>/<meter> (for
> example) to retrieve the actual values.

If /sources/<source> returns a list of meters, then I would think that
the appropriate URL construct would instead be this:

/sources/<source>/meters

Best,
-jay