[
https://issues.apache.org/jira/browse/SOLR-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987532#comment-14987532
]
Jeffrey Stylos commented on SOLR-8029:
--------------------------------------
Hi, IBM employee here — we use Solr in our Retrieve and Rank service and are
excited about a Solr v2 API to improve the usability of our service.
Some thoughts on the proposed changes:
/v2/ is more standard than /solr2/ (looks like others agree)
Having a path parameter (/v2/{collection}) at the top-level makes it difficult
to add new resources or other paths. A more REST-standard approach would be
preface path parameters with a static path value
(/v2/collections/{collection}). This would also allow the removal of the _
preface on _node and _cluster.
There is some inconsistency around naming style, with a mixture of snake_case,
hyphen-case, camelCase, unseparatedtext, and abbreviations. A v2 API would be a
good opportunity to make all of the identifiers use a consistent naming
convention.
On naming, we’ve found in API usability studies that acronyms and abbreviations
(like “wt”) make APIs harder to understand.
HOCON is an interesting suggestion, although I have some concerns about it from
a usability standpoint. In our API usability studies one of the most common
mistakes using JSON has been attempting to use single quotes instead of double
quotes — HOCON doesn’t fix this, and an fact can make things worse by resulting
in unexpected behavior ( https://github.com/akka/akka-meta/issues/2 ). By
attempting to be more permissive in its parsing, HOCON makes it more difficult
for a parser to generate helpful error messages (such as in the common
single-quote scenario). Breaking support for existing pretty printers and
syntax highlighters is also a concern.
One suggestion for an additional feature: a version date parameter, ala
FourSquare and Stripe, (?version=2015-11-03) would offer greater flexibility in
being able to evolve the API without breaking users.
And finally, a v2 would be a good time to question the core object model and
abstractions of the service.
(For reference, the API guidelines we use for IBM Watson APIs are public at:
https://github.com/watson-developer-cloud/api-guidelines.)
> 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: [email protected]
For additional commands, e-mail: [email protected]
