[Hawkular-dev] Hawkular Metrics - /data enpoint

[Stefan Negrea]

Most of the discussion so far in this thread was about accommodating
existing users. We could extend the support for the deprecated code for and
additional release (roughly one more month).

Here is my proposal
1) 0.15.0 - existing '*/data' endpoints are kept in place but deprecated
2) 0.16.0 - all '*/data' points are still kept but the GET endpoints will
be modified to serve only '*/stats' variant
3) 0.17.0 - purge all '*/data'

Step 2 above makes sense because the vast majority of our current consumers
use GET '/data' to retrieve bucketed results.

If there are no strong disagreements about the API change itself than it is
just a matter of finding the right balance to deprecate and remove the
existing endpoints. Any thoughts?


Thank you,
Stefan Negrea

Software Engineer

On Mon, Apr 4, 2016 at 9:21 AM, Matt Wringe <mwringe at redhat.com> wrote:

> ----- Original Message -----
> > From: "Heiko W.Rupp" <hrupp at redhat.com>
> > To: "Discussions around Hawkular development" <
> hawkular-dev at lists.jboss.org>
> > Sent: Monday, April 4, 2016 4:56:15 AM
> > Subject: Re: [Hawkular-dev] Hawkular Metrics - /data enpoint
> >
> > On 2 Apr 2016, at 0:24, Stefan Negrea wrote:
> > > The plan is to deprecate existing '*/data' endpoints in the upcoming
> > > release (0.15.0) and remove them in the release after that (0.16.0).
> That
> > > gives enough time (roughly 2 months) for all existing projects to
> migrate
> > > to the newer API. Does anybody see any problem with this timeline?
> >
> > Yes.
> > There are users out there that use the old api in production.
> > They may not even be aware that there is a new one.
> >
> > If they deploy the new hawkular-metrics (or someone does
> > for them), their apps will break and they may not even know
> > why.
>
> +1
>
> I think we need to make sure that we don't break the existing API for
> current users who are already using it. There will most likely be a bunch
> of complaints if we update this in OpenShift and then everyone's setup
> stops working.
>
> > REST allows for content negotiation. So we should keep the
> > old endpoint, deprecate them (and perhaps even spit regular
> > warnings in the logs) and on top add the new endpoints
> > that you suggested but with a new content type
> > like "application/json+hawkular-v2".
>
> If we are going to introduce a new version for the REST API, it might make
> sense to release Hawkular Metrics with a new major version as well. But
> major versions can be tricky depending on how the project handles them.
> Some projects will have the same major versions for years, others will
> update the major version almost monthly (eg kernel version versus browser
> version)
>
> > In fact if we keen old and new, that new content type
> > is not exactly needed if the data format exchanged does not
> > change.
> >
> > Btw: I doubt that GET ../data and POST ../data is confusing anyone
> > and in Jax-Rs you can have those on two different methods anyway.
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160404/993e5131/attachment-0001.html