You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Noble Paul (JIRA)" <ji...@apache.org> on 2015/09/10 16:37:46 UTC

[jira] [Comment Edited] (SOLR-8029) Modernize and standardize Solr APIs

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

Noble Paul edited comment on SOLR-8029 at 9/10/15 2:37 PM:
-----------------------------------------------------------

bq. 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.

Yes, we are doing a quick fix. Because anything else will also will look like a quick fix and {{api}} becomes a reserved name which cannot conflict with  a collection name. We should not make the new API look like  a second class citizen where I need to append an extra path to access that like {{solr/api/_cluster}}

Eventually , when we deprecate the legacy API, we should be able to get rid of the prefix altogether. 

At this point let us not discuss the "how" part. Let's define what an ideal solution should look like and fix that first. 


was (Author: noble.paul):
bq. 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.

Yes, we are doing a quick fix. Because anything else will also will look like a quick fix and {{api}} becomes a reserved name which cannot conflict with  a collection name. We should not make the new API look like  a second class citizen where I need to append an extra path to access that like {{solr/api/_cluster}}

Eventually , when we deprecate the legacy API, we should be able to get rid of the prefix altogether. 

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