You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Jason Gerlowski (Jira)" <ji...@apache.org> on 2023/02/15 15:24:00 UTC
[jira] [Commented] (SOLR-16488) Migrate ZookeeperReadAPI to JAX-RS
[ https://issues.apache.org/jira/browse/SOLR-16488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689195#comment-17689195 ]
Jason Gerlowski commented on SOLR-16488:
----------------------------------------
Alright, [I have a PR here|https://github.com/apache/solr/pull/1358] that does the mostly rote job of migrating ZookeeperReadAPI over to JAX-RS. Not quite ready to go: still needs tests, etc. But it should be far enough along to review.
There are only two big questions remaining at this point:
# What should we do with the v1 /admin/zookeeper endpoints? In some ways ZookeeperReadAPI is a v2 equivalent of those: like in that they offer near identical functionality. But in others ways, the APIs are weirdly unconnected: the response format is different, they don't share an underlying implementation in terms of the ZooKeeper interaction logic, etc.
# While we're migrating to JAX-RS, should we change the endpoints to be more in line with our overall REST-ful design for v2? If so, how?
For (1), I'd argue that we should deprecate /admin/zookeeper (probably in a separate ticket). Deprecation was proposed in SOLR-13942, but then never acted on for reasons that are unclear. I'll follow up on this in SOLR-13942.
For (2), I'd argue that we should update ZookeeperReadAPI in the following ways:
* "Fetch ZK Node" API
** Current: GET /api/cluster/zk/data/<zkPath>
** Proposed: GET /api/cluster/zookeeper/files/<zkPath> (We would maintain the special handling of security.json of course)
* "List Child Nodes"
** Current: GET /api/cluster/zk/ls/<zkPath>
** Proposed: GET /api/cluster/zookeeper/<zkPath>/children
These proposals aren't all that REST-ful. e.g. "List Child Nodes" does much more than listing child nodes, and its functionality should probably be split across multiple separate endpoints. But they should be good enough for a superficial fit with the remainder of our v2 surface area, and IMO those larger changes would be "scope-creep" at this point.
If no one has any suggestions or changes to those endpoint-tweaks I'll add that to the PR in the next few days.
> 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: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org