[jira] [Commented] (SOLR-16392) Cosmetic, REST-fulness improvements to v2 shard, replica, and replicaprop CRUD APIs

["Jason Gerlowski (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-16392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607968#comment-17607968 ] 

Jason Gerlowski commented on SOLR-16392:
----------------------------------------

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: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org