There's now some redundancy between the new /tags/delByQuery endpoint and the old /tags/delSeries. Unfortunately we have not much flexibility to change the /tags/delSeries endpoint, because that's part of the Graphite API, but could we maybe just extend it to also do what now /tags/delByQuery does?

The current request model for /tags/delSeries is this:

type GraphiteTagDelSeries struct {
	Paths []string `json:"path" form:"path"`
}

How about we extend it such that it looks like this:

type GraphiteTagDelSeries struct {
	Paths     []string `json:"path" form:"path"`
	Expr      []string `json:"expressions"`
	OlderThan int64    `json:"olderThan" form:"olderThan"`
	Execute   bool     `json:execute binding:"Default(false)"`
}

Then a user could simply choose whether they want to specify metrics using the metric names in .Paths or use tag query expressions (if they specify both I'd simply return an error).

There's now some redundancy between the new /tags/delByQuery endpoint and the old /tags/delSeries. Unfortunately we have not much flexibility to change the /tags/delSeries endpoint, because that's part of the Graphite API, but could we maybe just extend it to also do what now /tags/delByQuery does?

I wanted to purposefully add a separate, non-graphite endpoint. I don't see the benefit of munging together a graphite compatible endpoint and a graphite incompatible endpoint. Better to have distinct specific endpoints IMO.

I wanted to purposefully add a separate, non-graphite endpoint. I don't see the benefit of munging together a graphite compatible endpoint and a graphite incompatible endpoint.

isn't this what we already do with many of our endpoints? eg. we added metadata format to /render and you added lastts-jso to /tags/findSeries ? this seems similar

that said, i don't care about one way or another. if that was @replay 's only last remaining remark than it seems this is ready to merge?

isn't this what we already do with many of our endpoints? eg. we added metadata format to /render and you added lastts-json to /tags/findSeries ?

That's fair. I think the difference would be that there are effectively no overlapping params with the existing request.

I would like to leave this as a separate endpoint. I think that it is cleaner to have more targeted endpoints than multi-functional endpoints. Also, I know that @replay has expressed concern about accidental "overdeletion" with tagged expressions.

@shanson7 can you just update docs/http-api.md, then this will be good to merge according to @replay