Re: [Hawkular-dev] Hawkular Metrics - /data enpoint

On Mon, Apr 4, 2016 at 4:03 PM, John Sanda <jsanda(a)redhat.com&gt; wrote: > Making sure we don’t break clients is the most important aspect of > this; > however, there are some other questions I want to throw out. Today we > only > support clients adding raw data points. What if in the future though > we add > support for complex types like histograms and allow clients to > directly > store them. Would clients post that data to /raw, /stats, or > something else? > > Today we compute aggregated metrics at query time. We are going to > add > support for pre-computed aggregate metrics that are persisted. Do we > have > different endpoints for each? I haven’t thought about it too much > yet, but > I don’t separate endpoints is the way to go. > In the actual JIRA ticket there were 3 ideas floated around: separate endpoint, or /raw endpoint (because that is not bucketed data), or /stats endpoint (because is bucketed, just server side). And I think those are all the possible variations. One thing that I do not like about '/data' and pre-computed aggregates, if we do not split that method will serve 3 or 4 different formats depending on query params. That is way too complicated for both us and the users. > > With HWKMETRICS-373, we are introducing support for tag based > bucketing as > opposed to the date range bucketing already have. There are some > minor > differences in the data structures returned in the response, namely a > map > is returned instead of an array. Should we have a different endpoints > for > tag based buckets vs date range buckets? > I like the idea of just raw and stats. I associate /raw with raw data stored by Hawkular Metrics, and that includes pre-computed aggregates too, and /stats with some sort of statistical computation done do the raw data before returned to the user. Based on this, the tag querying would fall under '/stats' if data is bucketed and would fall under '/raw' if you query for just raw data that is tagged.