[
https://issues.apache.org/jira/browse/SOLR-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987885#comment-14987885
]
Shawn Heisey commented on SOLR-8029:
------------------------------------
Digging around in my pocket for a couple more pennies...
Consistency is probably the number one goal when an API is redesigned. There
better be a REALLY good reason for any deviations that result in special cases,
special syntax, etc. I think that /select and /update should NOT have special
shorter endpoints, and that identifiers should not have leading underscores (or
any other kind of unusual marking) unless they really are some kind of special
case that will only be used in highly unusual situations.
Related tangent: Using "/select" as the default query handler has always seemed
like a strange choice to me. Is this an opportunity to rename the default
query handler to /query for the v2 api?
Getting more detailed: It is probably a good idea to have a specific list of
legal values for the first URL path component after /v2 ... so only a list like
this is valid:
{code}
/v2/collection
/v2/node
/v2/cluster
/v2/core (might need this, if the implementation needs separation from
collection)
{code}
Standards for the next path component might be different for cluster than they
are for collection/node/core ... unless we implement a further abstraction
where SolrCloud can be a cluster of clusters.
> Modernize and standardize Solr APIs
> -----------------------------------
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
> Issue Type: Improvement
> Affects Versions: Trunk
> Reporter: Noble Paul
> Assignee: Noble Paul
> Labels: API, EaseOfUse
> Fix For: Trunk
>
>
> 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
