lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cassandra Targett (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs
Date Wed, 25 May 2016 21:10:14 GMT

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

Cassandra Targett commented on SOLR-8029:
-----------------------------------------

I've started doing a functional review of this, with a build from the apiv2 branch Noble has
been pushing to. I know I'll find more stuff, but as a first pass I noticed a few things to
start:

* Schema endpoints don't seem to include GET methods for fields, copyfields or dynamic fields.
I found the specs for them in {{core/src/resources/apispec}} ({{core.SchemaRead.fields.json}},
{{core.SchemaRead.copyFields.json}}), but I can't get to the endpoints referred to in those
spec files and they are not listed from an introspect request to the schema endpoint (i.e.,
{{http://localhost:8983/solr/v2/collections/apitest/schema/_introspect}}).
* I feel like there are similar GET endpoints missing from the {{config}} endpoint, but I'll
do some further analysis on that to be able to list them.
* Replacements for the Blob Store API and the ConfigSets API are not included?


> 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
>
>         Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch
>
>
> 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 4 types of requests in the new API 
> * {{/v2/<collection-name>/*}} : Hit a collection directly or manage collections/shards/replicas

> * {{/v2/<core>/*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection or core.
e.g: security, overseer ops etc
> 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


Mime
View raw message