lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noble Paul <noble.p...@gmail.com>
Subject Re: /v2 API -- will there ever be a /v3?
Date Thu, 03 Aug 2017 01:00:46 GMT
created a blocker ticket
https://issues.apache.org/jira/browse/SOLR-11183

On Thu, Aug 3, 2017 at 10:23 AM, Noble Paul <noble.paul@gmail.com> wrote:
> I shall open a ticket. let's resolve it there
>
> On Wed, Aug 2, 2017 at 5:30 AM, Jan Høydahl <jan.asf@cominvent.com> wrote:
>> 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
>>>>>>>
>>>>>
>>
>
>
>
> --
> -----------------------------------------------------
> Noble Paul



-- 
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message