<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I like option 1 as well. And thanks for the detailed explanation.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 14, 2016, at 4:42 AM, Joel Takvorian <<a href="mailto:jtakvori@redhat.com" class="">jtakvori@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hello,</div><div class=""><br class=""></div><div class="">Following the discussions here: <a href="https://github.com/hawkular/hawkular-metrics/pull/584" class="">https://github.com/hawkular/hawkular-metrics/pull/584</a> I would like to bring that up:</div><div class=""><br class=""></div><div class="">---------<br class=""></div><div class="">The problem<br class=""></div><div class="">I came to some limitation of the current REST API of hawkular-metrics when adding features to the Grafana plugin. The main point here is that because of an issue in Grafana (and/or golang) which you've certainly already discussed before I join, we're limited in the use of @get endpoints when metric ids are sent as query parameters. Although it has already been solved in the current version of the grafana plugin, the problem reappears when I'm trying to add features.</div><div class=""><br class=""></div><div class="">But beside those grafana centric considerations I think that it could be a good occasion to bring more consistency to the REST API when querying data for multiple metrics. There's several endpoints that, in my opinion, could be harmonized.</div><div class=""><br class=""></div><div class="">-----</div><div class="">So what's missing?</div><div class=""><br class=""></div><div class="">(note, by "*" I mean "gauges", "counters", "availability" or "string" ; not "metrics". When I write "/raw", same applies for "/rate".)<br class=""></div><div class=""><br class=""></div><div class="">- Some endpoints like "@get */stats" allow to query by list of ids or list of tags, but there's no equivalent on "@get */raw", and the "@post */raw/query" doesn't handle tags</div><div class="">Note that I've already opened a JIRA ticket for query-by-tag generalization: <a href="https://issues.jboss.org/browse/HWKMETRICS-466" class="">https://issues.jboss.org/browse/HWKMETRICS-466</a> . I can't find any good reason why we could do it when querying stats, but not when querying raw data.</div><div class=""><br class=""></div><div class="">- On the other hand, endpoints like "@post */raw/query", used for grafana, has no equivalent for "stats". I would really like to have this one for Grafana.</div><div class=""><br class=""></div><div class="">- List of metrics sometimes referred as "ids" (class QueryRequest), sometimes "metrics" (all @get query params). We could add "metrics" in QueryRequest but keep/deprecate "ids" for compatibility?</div><div class=""><br class=""></div><div class="">-----</div><div class="">Suggestions:</div><div class=""><br class=""></div><div class="">1st Option: keep the API in the current form and bring all endpoints up to the same level of functionality, that is:</div><div class=""> * Create "@get */raw" that can take ids or tags</div><div class=""> * Make "@post */raw/query" understand tags</div><div class=""> * Create "@post */stats/query" that can take ids or tags</div><div class=""><br class=""></div><div class="">---</div><div class="">2d Option: change the current model to dissociate query by ids or by tags</div><div class="">Basically the idea is to provide different path if we want to query by ids or by tags, to avoid having the assertion we currently have "must provide either ids or tags but not both". I think it's cleaner to separate them. Of course it has the downside of breaking (making deprecated) all query-by-tag in the current API.</div><div class=""><br class=""></div><div class="">So, queries by ids would be the default one:</div><div class=""> * "@get */raw"</div><div class=""> * "@get */stats"</div><div class=""> * "@post */raw/query"</div><div class=""> * "@post */stats/query"</div><div class="">None of them would accept tags</div><div class=""><br class=""></div><div class="">And query by tag would be:</div><div class=""> * "@get */raw/tags" (or "*/raw/tags/{tags}" ?)</div><div class=""> * "@get */stats/tags"</div><div class=""> * "@post */raw/tags/query"</div><div class=""> * "@post */stats/tags/query"</div><div class="">None of them would accept ids</div><div class=""><br class=""></div><div class="">---</div><div class="">Other Option?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">=> Personally, given the downside of the 2/ I would rather go for the 1st one.</div></div>
_______________________________________________<br class="">hawkular-dev mailing list<br class=""><a href="mailto:hawkular-dev@lists.jboss.org" class="">hawkular-dev@lists.jboss.org</a><br class="">https://lists.jboss.org/mailman/listinfo/hawkular-dev<br class=""></div></blockquote></div><br class=""></div></body></html>