I shall open a ticket. let's resolve it there On Wed, Aug 2, 2017 at 5:30 AM, Jan Høydahl <jan....@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 <ans...@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.p...@gmail.com> wrote: >> >> I meant /api in addition to /v2 >> >> On Jul 4, 2017 16:17, "Noble Paul" <noble.p...@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....@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 <ans...@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 <ans...@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....@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-unsubscr...@lucene.apache.org >>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>> >>>> >
-- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
