[
https://issues.apache.org/jira/browse/SOLR-16392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607968#comment-17607968
]
Jason Gerlowski edited comment on SOLR-16392 at 9/21/22 8:47 PM:
-----------------------------------------------------------------
I started working making the requisite changes for the REPLICAPROP related APIs
and ran into a bit of a snag.
Historically, V2HttpCall has determined whether a given API is an "admin"
request or a "core" request based on its path. Paths containing a
core/collection name are "core" requests, all others are considered "admin"
requests. V2HttpCall figures out what request-type its dealing with, and then
knows which PluginBag to look for an Api in. This works because the original
v2 API was designed with this heuristic in mind: it's one of the main reasons
that some paths (e.g. {{/collections}}) have so many sub-commands.
Unfortunately, this heuristic somewhat prevents the use of any more REST-ful
paths. Example: rewriting AddReplicaPropertyAPI to have the more REST-ful path
{{/collections/collName/shards/shardName/replicas/replicaName/properties/propName}}
leads to a 404 at runtime, as V2HttpCall sees the collection name and tries to
run the request using the core-level Jersey application. (AddReplicaPropertyAPI
is associated with CollectionsHandler and as such is registered with the
container-level Jersey app.)
If we're going to change these endpoints to be more intuitive and
user-friendly, we'll need to first rework V2HttpCall a bit to lookup endpoints
more intelligently. One barrier in this regard is that Jersey/JAX-RS doesn't
provide an easy way to check whether a given application has a match for a
particular incoming request, without actually submitting the request to Jersey
and executing it. The best we might be able to do here is a sort of "guess and
check", where we first try to serve a request from the core-container Jersey
app and then try on a core-specific Jersey app if Jersey spat out a
NotFoundException on our first attempt. It's a bit messy, but with the
interface that JAX-RS gives us, it might be our best option. Eager for other
suggestions though.
was (Author: gerlowskija):
I started working making the requisite changes for the REPLICAPROP related APIs
and ran into a bit of a snag.
Historically, V2HttpCall has determined whether a given API is an "admin"
request or a "core" request based on its path. Paths containing a
core/collection name are "core" requests, all others are considered "admin"
requests. V2HttpCall figures out what request-type its dealing with, and then
knows which PluginBag to look for an Api in. This works because the original
v2 API was designed with this heuristic in mind: it's one of the main reasons
that some paths (e.g. {{/collections}}) have so many sub-commands.
Unfortunately, this heuristic somewhat prevents the use of any more REST-ful
paths. Example: rewriting AddReplicaPropertyAPI to have the more REST-ful path
{{/collections/collName/shards/shardName/replicas/replicaName/properties/propName}}
leads to a 404 at runtime, as V2HttpCall sees the collection name and tries to
run the request using the core-level Jersey application. (AddReplicaPropertyAPI
is associated with CollectionsHandler and as such is registered with the
container-level Jersey app.)
If we're going to change these endpoints to be more intuitive and
user-friendly, we'll need to first rework V2HttpCall a bit to lookup endpoints
more intelligently. One barrier in this regard is that Jersey/JAX-RS doesn't
provide an easy way to check whether a given application has a match for a
particular incoming request, without actually submitting the request to Jersey
and executing it. The best we might be able to do here is a sort of "guess and
check", where we first try to serve a request from the core-container Jersey
app and then try on a core-specific Jersey app if Jersey spat out a
NotFoundException on our first attempt. It's a bit messy, but with the
interface that JAX-RS gives us, it might be our best option. Very open to
other suggestions though.
> Cosmetic, REST-fulness improvements to v2 shard, replica, and replicaprop
> CRUD APIs
> -----------------------------------------------------------------------------------
>
> Key: SOLR-16392
> URL: https://issues.apache.org/jira/browse/SOLR-16392
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
> Affects Versions: main (10.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
>
> As mentioned on SOLR-15781, the v2 API currently has an experimental
> designation, and the community has expressed an interest in using this period
> to update our v2 endpoints to be more REST-ful and consistent. The current
> plan is to follow the
> specific changes laid out in [this
> spreadsheet|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing],
> though of course nothing there is set in stone and there are still warts to
> be worked out.
>
> This ticket plans to tackle making the changes required for Solr's shard,
> replica and replica-prop CRUD APIs, as described in that spreadsheet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
