[
https://issues.apache.org/jira/browse/SOLR-17422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876964#comment-17876964
]
Eric Pugh commented on SOLR-17422:
----------------------------------
That's interesting... I wonder if in a list of code smells for REST end
points, seeing a lot of configurablity in how you query it implies that it
isn't well thought out. This is also why some folks like GraphQL type end
points, though I know that also has it's detractors.
I love the idea that we are starting to think about what a API *should* look
like, and using the V2 effort as an opportunity to make those changes, and not
just blindly copying them over. Nicer structured apis in V2 will make it more
attractive to swap over.
> Remove CLUSTERSTATE from v2; redundant
> --------------------------------------
>
> Key: SOLR-17422
> URL: https://issues.apache.org/jira/browse/SOLR-17422
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Reporter: David Smiley
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Revert SOLR-15748 – remove v2 /api/cluster being a CLUSTERSTATUS call
> The information (e.g. aliases, or the status of one collection, live nodes,
> etc.) should be made available via V2 but we don't need a macro API to return
> a bunch of these things at once, which is what CLUSTERSTATUS is. I suspect
> CLUSTERSTATUS may have been one of the original SolrCloud level APIs so it
> became a kitchen sink of all things about the state/status. In hindsight, I
> don't agree with it. It ends up blowing up in size for clients that only
> need a subset of it, leading to decomposing it – SOLR-17381.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
