lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <>
Subject Re: /v2 API -- will there ever be a /v3?
Date Tue, 01 Aug 2017 20:00:19 GMT
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


> Den 1. aug. 2017 kl. 20.32 skrev Anshum Gupta <>:
> 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 <> wrote:
>> I meant /api in addition to /v2 
>>> On Jul 4, 2017 16:17, "Noble Paul" <> 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" <> wrote:
>>>> I’ll let this email thread run a little bit longer to gather different
>>>> 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
>>>> --
>>>> Jan Høydahl, search solution architect
>>>> Cominvent AS -
>>>>> 3. jul. 2017 kl. 22.57 skrev Anshum Gupta <>:
>>>>> 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 <>
>>>>>> +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 <>
>>>>>>> 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 -
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:
>>>>>>> For additional commands, e-mail:

View raw message