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 >
