Sorry for entering the discussion so late with my two cents below, but perhaps I can add some more insights from a consumer's perspective and help answer the question "to what direction should we head with v2 API".
In a previous discussion a couple months ago, Jason and I were talking about "REST"ful APIs, mainly from a consumer's perspective, but also for determining the API endpoints. We were trying to define what the structure of the API endpoints should be, and what data should be provided by each endpoint, with the goal to also avoid duplicated data across endpoints. In a RESTful API, we are normally talking about resources. The v2 proposal page in the spreadsheet [1] was aiming for defining the resources we have in Solr at API level, without being influenced from internal structure or implementation details. Taking the discussion's outcome, /api/cluster would fetch a single resource element, the cluster, and provide information about the cluster. Not the nodes, not the shards, not collections. If we are interested in nodes, we would use the resource collection GET /api/nodes, optionally with some query parameters like status=healthy. By focusing on what a resource is and what information it carries (scoped), we would avoid super-endpoints that provide too much information, like the CLUSTERSTATUS does right now. The new Admin UI is also applying the concept of resources in the designs. I am not sure if we want to follow that ideology, but it could definitely help against excessive data exposure from single endpoints. The SOLID principles would also take effect in various ways. [1] https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?pli=1&gid=1878317994#gid=1878317994 On 2026/09/08 11:19:26 Eric Pugh wrote: > Hi all, spelunking a bit through what API to convert from our old homegrown > V2 and to the Jax RS V2 approach, and I noticed that CLUSTERSTATUS is one > that is used to drive a lot of our Admin UI. So I thought, hey, that will > be an easy migration. > > I found this closed (but not merged) PR: > https://github.com/apache/solr/pull/2670 from David, and this JIRA > https://issues.apache.org/jira/browse/SOLR-17422. > > Before I go down the path of making some more JIRAs for various V2 api work > for folks to pick up, at least for CLUSTERSTATUS, I wanted to see if anyone > had sketched out what we WANT the API structure to look like? > > I had a comment from two years ago on this, but hadn’t done anything about > it….. > > Eric > > Disclaimer > > The information contained in this communication from the sender is > confidential. It is intended solely for use by the recipient and others > authorized to receive it. If you are not the recipient, you are hereby > notified that any disclosure, copying, distribution or taking action in > relation of the contents of this information is strictly prohibited and may > be unlawful. > > This email has been scanned for viruses and malware, and may have been > automatically archived by Mimecast, a leader in email security and cyber > resilience. Mimecast integrates email defenses with brand protection, > security awareness training, web security, compliance and other essential > capabilities. Mimecast helps protect large and small organizations from > malicious activity, human error and technology failure; and to lead the > movement toward building a more resilient world. To find out more, visit our > website. > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
