[Hawkular-dev] Hawkular Metrics - /data enpoint

[Heiko W.Rupp]

On 5 Apr 2016, at 0:18, Stefan Negrea wrote:

> On Mon, Apr 4, 2016 at 4:03 PM, John Sanda <jsanda at redhat.com> 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.


John wrote about "tag based bucketing as opposed to the date range 
bucketing"

So both is bucket data and both /stats -- but with different return 
types.
If this is true, they need to return different content-types. This can 
not just
be returned like so without any notice to the used and the user doing 
the
guesswork.