Hi Inosh, It was not originally planned, but it looks like we'll be albe to get it through.
Thanks, NuwanD. On Sunday, April 20, 2014, Inosh Goonewardena <in...@wso2.com> wrote: > Hi Nuwan, > > Do we have this feature included in APIM-1.7.0 release? > > > On Mon, Mar 17, 2014 at 1:38 PM, Nuwan Dias <nuw...@wso2.com> wrote: > > On Mon, Mar 17, 2014 at 2:44 PM, Isuru Perera <isu...@wso2.com> wrote: > > Can a user decide to change the default version API when he can make sure > that all apps work with new API? Or the user can publicly announce the > default API is changing and give some time to change. > > So, in summary, there can be a requirement to change the default API and > it seems to be a reasonable requirement for me. Just asking. > > Yes this is possible. What you're talking here is about changing the > 'implementation' of the default version api. So you have an api as /twitter > which performs operations 'a' and 'b'. You're now going to make it perform > operation 'c'. So you announce that /twitter is about to change in 2 months > time and at the end of two months, you change /twitter so that it now bears > the new contract. This would mean that apps still using the old contract > will break. > > During our discussion with the ESB team we talked about the possibility of > making the Gateway intelligent enough so that it can handle both old and > new api requests on a single context. I wanted to highlight the fact that > we dropped the idea since it would make the implementation overly > complicated and give back very less in return. > > Thanks, > NuwanD. > > > On Mon, Mar 17, 2014 at 12:39 PM, Nuwan Dias <nuw...@wso2.com> wrote: > > Let's consider we have the following APIs > > /twitter/ > /twitter/1.0.0 > /twitter/2.0.0 > > When a request is made as http://host:port/twitter/1.0.0, there is no > guarantee whether it is /twitter or /twitter/1.0.0 that is being invoked. > Since the *isMatchingVersion* function in RESTRequestHandler always > returns true for /twitter, if /twitter stands higher in the list, it will > be matched and invoked. To avoid this, we will be reordering the api list > so that /twitter gets the last position of the list. Therefore /twitter > will only be invoked if there is no matching version found. > > The following limitations apply when we're having an API as a default > version API > > a) Once you define a default version API, it remains final and cannot > change. This means that you cannot go and assign a version to it on a later > day. The reason for this is because it will cause client applications to > fail since you are changing the contract. > > b) The above would mean that if you already have a default version API, > you cannot mark a new API as a default version API. This sounds fair enough > to me because you are trying to expose a new contract over an old interface > and this would again cause old apps to break. > > Thanks, > NuwanD. > > > > > On Fri, Mar 14, 2014 at 3:21 PM, Malintha Amarasinghe > <malint...@wso2.com>wrote: > > Hi All, > > When exposing APIs, API Manager uses existing synapse core, which is > already used in WSO2 ESB. Because of that, the behavior of APIs which does > not having version attributes can be tested by defining similar APIs in > synapse configuration in an ESB instance. > > Regards, > > Inosh Goonewardena > Associate Technical Lead- WSO2 Inc. > Mobile: +94779966317 > -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
