On Sun, Apr 20, 2014 at 6:29 PM, Nuwan Dias <nuw...@wso2.com> wrote: > Hi Inosh, > > It was not originally planned, but it looks like we'll be albe to get it > through. >
Great. Thanks for the information. > > 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 > > -- Regards, Inosh Goonewardena Associate Technical Lead- WSO2 Inc. Mobile: +94779966317
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
