lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anshum Gupta <ans...@anshumgupta.net>
Subject Re: /v2 API -- will there ever be a /v3?
Date Tue, 01 Aug 2017 18:32:21 GMT
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