<br><br><div class="gmail_quote">On Mon, Aug 6, 2012 at 6:31 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 08/06/2012 06:02 PM, Doug Hellmann wrote:<br>
> I've submitted a patch to implement a few of the queries for meter event<br>
> data using the "project" filter. As you can see from the diff [1], there<br>
> are now 16 separate routes pointing to the same simple function that<br>
> calls the database backend. This smells bad, so I would like to propose<br>
> changing the API to remove some of the duplication.<br>
><br>
> First, when asking for values about a given resource, there isn't any<br>
> reason to specify the user or project because they won't change for a<br>
> given resource. I don't think it's going to be useful to ask for a<br>
> complete dump of all of the metering data for a user at one time, since<br>
> the events will refer to different resources and meters. That eliminates<br>
> several variations, so instead of 16 URLs listed in the current<br>
> implementation, we have 3:<br>
><br>
> /users/<user>/<meter><br>
> /projects/<project>/<meter><br>
> /resource/<resource>/<meter><br>
<br>
</div>I assume you mean:<br>
<br>
/resources/<resource>/<meter><br></blockquote><div><br></div><div>Yes, thanks for catching that. When in doubt, assume I mean to be consistent. :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> For the supported calculations, we would add "/duration" or "/volume" to<br>
> the end of the above URLs. That's 2 sets of 3 more URLs, with each set<br>
> pointing to a function to do that calculation for us.<br>
<br>
</div>OK.<br>
<div class="im"><br>
> For /resources/<resource> the metadata for the resource is returned<br>
> (including the list of meters reporting).<br>
><br>
> These forms:<br>
><br>
> /users/<user><br>
> /projects/<project><br>
><br>
> return the list of resources owned by the user or project.<br>
<br>
</div>I think it would be better to do:<br>
<br>
/users/<user>/resources<br>
/projects/<project>/resources<br>
<br>
Since you would be being explicit about the resource/document returned.<br>
<br>
Further, you would limit the return to a single resource document like so:<br>
<br>
/users/<user>/resources/<resource> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the same vein, I think it would be better to have:<br>
<br>
/users/<user>/meters/<meter><br>
<br>
instead of:<br>
<br>
/users/<user>/<meter><br>
<br>
For the same reason: you are being explicit that a <meter> is a resource<br>
of which a user has many, and you are selecting a specific meter<br>
resource from the list of a user's meters.<br></blockquote><div><br></div><div>OK, I can see that. What I wanted to avoid was someone thinking that /users/<user> would return anything about the user, since we don't really have any interesting metadata about the user object itself.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> I'm not sure what to do with "source." It seems like a source should<br>
> just tell us about the list of meters is provides, and then we should<br>
> ask for the meter data in the usual way. So /sources/<source> returns a<br>
> list of meter names, and we use /resources/<resource>/<meter> (for<br>
> example) to retrieve the actual values.<br>
<br>
</div>If /sources/<source> returns a list of meters, then I would think that<br>
the appropriate URL construct would instead be this:<br>
<br>
/sources/<source>/meters<br>
<br>
Best,<br>
-jay<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br>