[
https://issues.apache.org/jira/browse/SOLR-16488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692717#comment-17692717
]
Jason Gerlowski commented on SOLR-16488:
----------------------------------------
OK, let's move the zkPath into the query params. Once you do that, I'm not
sure the "files" path segment still makes sense. "/files/children" in
particular feels a little awkward. Instead we could use "data" and "children"
path segments, which is pretty similar to the existing API if "ls" were swapped
for "children".
* "Fetch Zk Node" API
** Proposed: GET /api/cluster/zookeeper/data?path=zkPath
* "List Child Nodes" API
** GET /api/cluster/zookeeper/children?path=zkPath
How does that look to everyone?
bq. the old /admin/zookeeper it is soo different from the new and will take
lots of effort to move the Admin UI over. So I'd argue treating it as a
separate API
I don't have any problem with that conceptually if someone wants to give
ZooKeeperInfoHandler a v2 equivalent. And "/tree" sounds like a reasonable
subpath, given my understanding of that functionality. But I'm not going to
put it on my personal list any time soon. There's too much v2 work that needs
done for the APIs everyone agrees we actually need to spend any time on an API
that there's consensus on nuking as soon as we can find out how.
bq. since you are already critically thinking about this, you create the list
of JIRA's to split it up across mulitple seperate endpoints [...] I say this as
someone who is following the almost five year old receipe laid out in SOLR-8975
I see I'm caught in a trap of my own setting. This feels a little different
from SOLR-8975 though, as it's not a large task that's divide-and-conquer-able
in the same way. I really just have one change in mind.
What we've been calling the "list children API" in this discussion actually
does two things conceptually: it lists out the children of the specified node,
but it also returns the 'stat' for the current node and for each child. So the
response actually returns as:
{code}
{
responseHeader: {...},
stat: {...statInfo...},
/specifiedNode: {
child1: {...statInfo...},
child2: {...statInfo...}
}
{code}.
My suggestion is that we split that up into two different APIs. One that
returns the list of child nodes and nothing else, and one that can be used to
fetch the stat info for a single node.
That's about all the context I've got if you still think it's worth filing a
JIRA for down-the-road.
> Migrate ZookeeperReadAPI to JAX-RS
> ----------------------------------
>
> Key: SOLR-16488
> URL: https://issues.apache.org/jira/browse/SOLR-16488
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
> Affects Versions: 9.1, main (10.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Labels: newdev
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> EDIT: This description originally described creating a plan for creating v2
> APIs equivalent to the current v1 /admin/zookeeper endpoints. But it turns
> out that equivalent v2 APIs already largely exist in ZookeeperReadAPI. The
> description has updated to reflect this.
> The ZookeeperReadAPI APIs should be migrated to JAX-RS and be tweaked to be
> more REST-ful and in line with the direction we're pushing v2 in. See the
> comments below for a discussion of specific tweaks to the HTTP path,
> parameters, etc. for these APIs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
