Hi Jan, "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."
I think this makes a lot os sense now that you pointed it out. +1 to what David suggested On Mon, Jul 3, 2017 at 1:12 PM, Jan Høydahl <jan....@cominvent.com> wrote: > Thanks Shawn, David and Ishan. Don’t know how to interpret the silence. > Does it mean that the rest of you believe /v2/ is the best naming? > > My intention is not to spark a discussion war, but to make sure there is > consensus on this before 7.0 release. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 16. jun. 2017 kl. 21.58 skrev Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>: > > My concern with /api is that handling backcompats between versions (v2 to > v3 etc.) is problematic; and if we decide not to support backcompat, then > it could be a source of confusion for the user. > > I'm +1 for /v2 or /api/v2 (and v3 etc. going forward). > > On Fri, Jun 16, 2017 at 10:53 PM, David Smiley <david.w.smi...@gmail.com> > wrote: > >> +1 to remove the "v2" in the URL or make it an optional add-on (e.g. /api >> or /api/v2). Any/all of the proposals by Jan & Shawn sound reasonable to >> me. >> >> >> On Fri, Jun 16, 2017 at 9: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 >>> >>> -- >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> http://www.solrenterprisesearchserver.com >> > > >
