lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <jan....@cominvent.com>
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
patch?

Jan

> Den 1. aug. 2017 kl. 20.32 skrev Anshum Gupta <anshum@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.paul@gmail.com> wrote:
>> I meant /api in addition to /v2 
>> 
>>> On Jul 4, 2017 16:17, "Noble Paul" <noble.paul@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.asf@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 <anshum@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 <anshum@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.asf@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-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>> 
>>>> 

Mime
View raw message