lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ishan Chattopadhyaya <ichattopadhy...@gmail.com>
Subject Re: /v2 API -- will there ever be a /v3?
Date Sun, 20 Aug 2017 04:29:10 GMT
I just realized that this issue was deprioritized from being a blocker. I
strongly believe that this should be done now (7.0) to avoid user confusion
going forward. I added a simple patch there (SOLR-11183); can someone
please take a look?

On Thu, Aug 3, 2017 at 6:30 AM, Noble Paul <noble.paul@gmail.com> wrote:

> created a blocker ticket
> https://issues.apache.org/jira/browse/SOLR-11183
>
> On Thu, Aug 3, 2017 at 10:23 AM, Noble Paul <noble.paul@gmail.com> wrote:
> > I shall open a ticket. let's resolve it there
> >
> > On Wed, Aug 2, 2017 at 5:30 AM, Jan Høydahl <jan.asf@cominvent.com>
> wrote:
> >> Thanks for following up, Anshum. I'm on holiday so not much online..
> >>
> >> Can you create a blocker JIRA to formally force a decision and provide a
> >> place to upload a patch?
> >>
> >> Jan
> >>
> >> Den 1. aug. 2017 kl. 20.32 skrev Anshum Gupta <anshum@anshumgupta.net>:
> >>
> >> Bumping this up.
> >>
> >> Last call in case we want to change the endpoint, which I think we
> should!
> >>
> >> Anshum
> >>
> >> On Mon, Jul 3, 2017 at 11:52 PM Noble Paul <noble.paul@gmail.com>
> wrote:
> >>>
> >>> I meant /api in addition to /v2
> >>>
> >>> On Jul 4, 2017 16:17, "Noble Paul" <noble.paul@gmail.com> wrote:
> >>>>
> >>>> /api is ok. It takes a non trivial amount of time to make this
> change. I
> >>>> would not want to hold up the release for this. We can easily add
> support
> >>>> for /api in addition to /api in the next release
> >>>>
> >>>>
> >>>> On Jul 4, 2017 08:35, "Jan Høydahl" <jan.asf@cominvent.com> wrote:
> >>>>>
> >>>>> I’ll let this email thread run a little bit longer to gather
> different
> >>>>> views.
> >>>>> Then in a few days we can try to discover a consensus and create
a
> JIRA.
> >>>>>
> >>>>> I think that the effort gone into moving Solr to root context allows
> us
> >>>>> great flexibility, whatever naming we want.
> >>>>> As I said, I don’t think an app like Solr needs to keep older
API
> >>>>> versions alive for more than one major version, like a public web
> service
> >>>>> API would need.
> >>>>>
> >>>>> In 7.x we’ll have both /api/ and (deprecated) /solr
> >>>>> In 8.x we’ll have only /api/ (?)
> >>>>>
> >>>>> If we then in e.g. 12.x want to introduce a v3 thing, we could map
> it to
> >>>>> /api/v3 and move it to /api/ in 13.x, with /api/v3 as an alias.
> >>>>> We could even let users configure “v2RootPath” and “v3RootPath”
at
> will
> >>>>> if they need to adapt to some client need and do not want to use
a
> reverse
> >>>>> proxy for that.
> >>>>>
> >>>>> --
> >>>>> Jan Høydahl, search solution architect
> >>>>> Cominvent AS - www.cominvent.com
> >>>>>
> >>>>> 3. jul. 2017 kl. 22.57 skrev Anshum Gupta <anshum@anshumgupta.net>:
> >>>>>
> >>>>> Also, if someone has the time to take this up, can you please create
> a
> >>>>> JIRA and mark is a usability blocker for 7.0 release ?
> >>>>>
> >>>>> -Anshum
> >>>>>
> >>>>> On Mon, Jul 3, 2017 at 1:55 PM Anshum Gupta <anshum@anshumgupta.net>
> >>>>> wrote:
> >>>>>>
> >>>>>> +1 to not  having v2. I don't have a personal preference between
the
> >>>>>> suggestions by Shawn, and Jan, so like David, either of them
would
> be great.
> >>>>>>
> >>>>>> -Anshum
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jun 16, 2017 at 6:59 AM Jan Høydahl <jan.asf@cominvent.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Now that we’re getting used to thinking localhost:8983/v2/
as the
> new
> >>>>>>> api entry point, just one silly question:
> >>>>>>>
> >>>>>>> Will we ever move beyond /v2/ to /v3/?
> >>>>>>>
> >>>>>>> The answer may seem obvious to many of you and may have
consensus
> in
> >>>>>>> some looong JIRA discussion that I did not follow.
> >>>>>>>
> >>>>>>> But I have a sneaking feeling that we’ll still be at /v2/
5 years
> from
> >>>>>>> now and that we’ll use other mechanisms for
> >>>>>>> making breaking changes in one or more of the APIs, rather
than
> >>>>>>> bumping the main entry point, which has a high cost.
> >>>>>>> In this regard I believe perhaps Solr as an app is different
from
> any
> >>>>>>> publicly available SAAS out on the internet,
> >>>>>>> and if someone needed to publish a Solr search to a bunch
of
> unknown
> >>>>>>> clients they would not expose Solr to those
> >>>>>>> clients but rather their own proxy, and the whole /v2, /v3
thing
> would
> >>>>>>> be controlled by their API layer above Solr.
> >>>>>>>
> >>>>>>> Feel free to shoot me down, but is localhost:8983/api/ a
more
> honest
> >>>>>>> naming for v2?
> >>>>>>> * It looks much better
> >>>>>>> * It is intuitive to everyone
> >>>>>>> * It never gets outdated
> >>>>>>> * We can still move to /api/v3 or anything else in the future
if
> so be
> >>>>>>>
> >>>>>>> So if my gut feeling is wrong here, please tell me a likely
event
> in,
> >>>>>>> say Solr8 that would warrant a /v3 in parallel
> >>>>>>> with /v2. If this is something that will happen once every
5 years
> and
> >>>>>>> not once every major version, then perhaps
> >>>>>>> other ways of versioning is more appropriate? (HTTP headers?,
API
> >>>>>>> paths /api/c/foo/backup2 ...)?
> >>>>>>>
> >>>>>>> --
> >>>>>>> Jan Høydahl, search solution architect
> >>>>>>> Cominvent AS - www.cominvent.com
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------------------------------
> ---------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>
> >>>>>
> >>
> >
> >
> >
> > --
> > -----------------------------------------------------
> > Noble Paul
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Mime
View raw message