[
https://issues.apache.org/jira/browse/SOLR-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14738893#comment-14738893
]
Shawn Heisey commented on SOLR-8029:
------------------------------------
I had not considered the idea of a conflict with a collection or core named
api. That is a potential problem.
Forgetting about implementation for the discussion is a good idea, but I think
the URL path is important even if we don't consider how we're going to do it.
I think that stepping away from the default /solr prefix, especially if that is
a temporary change that we then change back in next major version's example, is
going really irritate users. I believe that if we are going to change the URL
path, it should remain under /solr (or whatever the user chose for the
context), and be a permanent move.
I wonder if you could have the implementation work in such a way that
/solr/api/select (and friends) would still work for a collection named api, and
/solr/api/api/select (or however we arrange the lower bits of a new structure)
would ALSO work. We could also declare (and document) that if the new APIs are
enabled, a core named api will no longer be accessible.
/solr/v2 is another idea, but I do not want anyone to get tied to a specific
version in the base URL, and there is still the possibility that a user has a
core with a conflicting name.
bq. Did we not already get rid of the concept that "solr is a webapp"
We got rid of the concept from the user perspective, but it is still a crucial
detail of our implementation. We have talked about changing that, but it is
our reality for the moment, and once we get to the implementation, it will have
to be factored in.
I don't want anyone to think that any of my ideas or criticisms are an
indication of an automatic -1 vote. I think the general idea here is VERY
good, but that the proposed plan could be improved. If everyone disagrees with
me, then I will adapt ... and try not to be mean if my concerns become real.
> 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
> Labels: API, EaseOfUse
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
