[
https://issues.apache.org/jira/browse/SOLR-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14738807#comment-14738807
]
Shawn Heisey commented on SOLR-8029:
------------------------------------
The path "/solr2" rubs me the wrong way. It implies to a user that we didn't
think it through originally, had to change it, and just tacked on a number.
We'll be stuck with it forever to avoid future compatibility problems. Users
may start to wonder when version 3 will come out and force them to change all
their software *again*. Using something like /solr/api, with all the old paths
working until explicitly disabled in the config or the next major version comes
out, will look like a well-planned and permanent change to users. If we use
"/solr2" it might look like we are quickly fixing a major oops with a temporary
URL path that will disappear in a future version.
I don't like the idea of deploying the context at the root, but it's not a BAD
solution if we do it right. If we do that, the URL path should remain
configurable, so a user can use /fahrbot if they want to. One problem with
this is that suddenly it becomes Solr's responsibility to make sure that path
works correctly throughout the application. Jetty has had a very long time to
work out any bugs with custom context paths ... we would be starting from
scratch.
I know that we might be starting from scratch with supporting a configurable
path when we shed the webapp and become a standalone application, so that part
of my thoughts might be moot.
> Modernize and standardize Solr APIs
> -----------------------------------
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 6.0
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 6.0
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with
> each other or not in sync with the widely followed conventions of HTTP
> protocol. Trying to make incremental changes to make them modern is like
> applying band-aid. So, we have done a complete rethink of what the APIs
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy
> APIs will continue to work under the {{/solr}} path as they used to and they
> will be eventually deprecated.
> There are 3 types of requests in the new API
> * {{/solr2/<collection-name>/*}} : Operations on specific collections
> * {{/solr2/_cluster/*}} : Cluster-wide operations which are not specific to
> any collections.
> * {{/solr2/_node/*}} : Operations on the node receiving the request. This is
> the counter part of the core admin API
> This will be released as part of a major release. Check the link given below
> for the full specification. Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
