Resending to Architecture Thanks
*Dinesh J. Weerakkody* Software Engineer WSO2 Inc. lean | enterprise | middleware M : +94 727 361788 | E : [email protected] | W : www.wso2.com On Mon, Jan 26, 2015 at 1:04 PM, Dinesh J Weerakkody <[email protected]> wrote: > Hi All, > > We had a review meeting on 23 Jan 2015 to review the progress of this > feature. Following points were discussed during the meeting. > > > > > > > - RXT file which is created in registry at API creation time will > contain new two field. (Data migration is required when upgrading existing > APIs to new version) > - version-type Ex: none, url, context > - context-template Ex: /{version}/api) > - Resolved context will be stored in the APIM database since those > data is used in key validation service in runtime > - Synapse XML will contain the context template as the context and > will be resolved in deployment time. New version strategy > (ContextVersionStratergy) will be introduced to Sysnapse > - Version strategy used in API will be set to the synapse message > context from synapse side when API is invoked. This will be used in APIM > side when retrieving the details in URL. > > Please add if I have missed anything. > > > > > Thanks > > *Dinesh J. Weerakkody* > Software Engineer > WSO2 Inc. > lean | enterprise | middleware > M : +94 727 361788 | E : [email protected] | W : www.wso2.com > > On Thu, Jan 15, 2015 at 8:08 AM, Dinesh J Weerakkody <[email protected]> > wrote: > >> >> On Thu, Jan 15, 2015 at 12:17 AM, Nuwan Dias <[email protected]> wrote: >> >>> >>> On Tue, Jan 13, 2015 at 11:11 AM, Dinesh J Weerakkody <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> >>>> I have tested the above proposed method with a fresh APIM 1.8 pack. We >>>> can successfully create and invoke APIs as follows. >>>> >>>> [image: Inline image 1] >>>> >>>> Here what we do is simply add the version number to context. Also I >>>> have removed version from the resulting synapse api xml file (smiler to >>>> default version) otherwise we have to send version number after the context >>>> (Ex: http://localhost:8280/1.0.0/docman/*1.0.0*/add). >>>> >>>> Now we can invoke this API as follows since context is matching to >>>> request url and this is default version. >>>> http://localhost:8280/1.0.0/docman/add >>>> >>>> With the above solution system doesn't allow us to create a new version >>>> of the API. Currently synapse doesn't allow to use deferent contexts with >>>> same API name. >>>> Ex: >>>> Name : DOCMan >>>> Context : */1.0.0/docman* >>>> Version: 1.0.0 >>>> >>>> Name : DOCMan >>>> Context :* /2.0.0/docman* >>>> Version: 2.0.0 >>>> >>>> We used a template as a context to overcome this situation. >>>> >>>> [image: Inline image 2] >>>> >>> >>> I don't think we should be using {uri.var.version} since it confuses >>> with uri-templates. What if we just use {version} instead? >>> >> >> >> Yes, we can use {version} or any string. I just used {uri.var.version} >> for the time been. >> >> >>> >>>> With this solution context will be same among all versions. We resolve >>>> the context template when API is initializing in synapse runtime. There is >>>> another issue came up with this solution. Synapse doesn't allow to use >>>> version attribute in API xml without a version-type (version strategy) >>>> attribute. URL is the only value that we can use with the version-type >>>> attribute and when we invoke api we must send version after the context if >>>> we use URL as the version strategy. We can introduce a new version strategy >>>> to overcome this situation. For the time been I have disabled the >>>> validation. >>>> >>>> After above mentioned changes we can successfully deploy multiple >>>> versions of the same API. But when we try to invoke the APIs we faced >>>> another issue. When the request comes to APIM side there is a problem in >>>> authentication handler. >>>> >>>> We use context to check whether access is granted to the given token or >>>> not. In APIM side tables we have context template but in runtime we send >>>> resolved context. So there will be no matching access grants and request >>>> will be rejected. >>>> >>> >>> What if we store the resolved context in the database rather than >>> storing the template? >>> >> >> We need to keep context template also. We have to display it back in edit >> page and also use when we update the API from APIM side. >> >> >>> >>>> We have two solutions to overcome this issue. >>>> >>>> - Have a separate column in APIM database to store the resolved >>>> context (Use in runtime) >>>> - Add a new attribute to RXT to store context template (This is >>>> used to display the context template in UI when editing the API) >>>> >>>> I think that the second option is better than adding new columns to the >>>> tables. >>>> >>>> Please share your suggestions or thoughts on this. >>>> >>>> >>>> >>>> >>>> Thanks >>>> >>>> *Dinesh J. Weerakkody* >>>> Software Engineer >>>> WSO2 Inc. >>>> lean | enterprise | middleware >>>> M : +94 727 361788 | E : [email protected] | W : www.wso2.com >>>> >>>> On Tue, Dec 23, 2014 at 5:43 PM, Dinesh J Weerakkody <[email protected]> >>>> wrote: >>>> >>>>> *Participants* >>>>> APIM Team : Sumedha, Nuwan, Sanjeewa, Jo, Roshan, Lakshman, Dinesh >>>>> ESB Team : Kasun >>>>> >>>>> *Redmine* >>>>> https://redmine.wso2.com/issues/153 >>>>> >>>>> We have discussed the following options as solutions to implement a >>>>> pluggable version strategy for APIM manager product. >>>>> >>>>> *Option 1 : include version to context path* >>>>> We allow users to define API context as a template in API create UI. >>>>> Context = /api/{uri.var.version}/anytext >>>>> Version = 1.0.0 >>>>> >>>>> Then we generate the context path based on a the template when >>>>> creating the synapse xml and use default version-type (empty). >>>>> >>>>> *Current version* >>>>> <api xmlns="http://ws.apache.org/ns/synapse"; >>>>> name="admin-API" >>>>> context="/api” >>>>> version="1.0.0" >>>>> *version-type="url"*> >>>>> >>>>> *Proposed version* >>>>> <api xmlns="http://ws.apache.org/ns/synapse"; >>>>> name="admin-API" >>>>> *context="/api/1.0.0"* >>>>> version="1.0.0"> >>>>> >>>>> Please note that version appended to context while version tag keeping >>>>> as it is. If user does not include the {uri.var.version}, current process >>>>> will be used. >>>>> >>>>> Ex: >>>>> context="/1.0.0/api" >>>>> context="/gov/1.0.0/api" >>>>> context="/gov/1.0.0/api2" >>>>> >>>>> *Option 2 : Match APIs based on configured context pattern* >>>>> <api xmlns="http://ws.apache.org/ns/synapse"; >>>>> name="admin-API" >>>>> context-pattern=”{uri.var.context}/{uri.var.version}” >>>>> context="/api” >>>>> version="1.0.0" >>>>> version-type="url"> >>>>> >>>>> Ex: >>>>> {uri.var.version}/{uri.var.context}= http://localhost:8280/1.0.0/api >>>>> {uri.var.context}/{uri.var.version}= http://localhost:8280/api/1.0.0/ >>>>> >>>>> In synapse level we have to uniquely identify a API with the context >>>>> and version. With second option, it will be difficult and can be lead to >>>>> conflicts If user define an API with context=”1.0.0” version=”api” while >>>>> having an API with context=”api” version=”1.0.0”. So we have decided to >>>>> drop the second option and throughly test the first option. >>>>> >>>>> Please share your suggestions or thoughts on this. >>>>> >>>>> >>>>> Thanks >>>>> >>>>> *Dinesh J. Weerakkody* >>>>> Software Engineer >>>>> WSO2 Inc. >>>>> lean | enterprise | middleware >>>>> M : +94 727 361788 | E : [email protected] | W : www.wso2.com >>>>> >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Associate Tech Lead - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 >>> >> >> >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
