created a blocker ticket https://issues.apache.org/jira/browse/SOLR-11183
On Thu, Aug 3, 2017 at 10:23 AM, Noble Paul <[email protected]> wrote: > I shall open a ticket. let's resolve it there > > On Wed, Aug 2, 2017 at 5:30 AM, Jan Høydahl <[email protected]> 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 <[email protected]>: >> >> 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 <[email protected]> wrote: >>> >>> I meant /api in addition to /v2 >>> >>> On Jul 4, 2017 16:17, "Noble Paul" <[email protected]> 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" <[email protected]> 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 <[email protected]>: >>>>> >>>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>> >> > > > > -- > ----------------------------------------------------- > Noble Paul -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
