On Thu, Jan 15, 2015 at 12:17 AM, Nuwan Dias <nuw...@wso2.com> wrote:
> > On Tue, Jan 13, 2015 at 11:11 AM, Dinesh J Weerakkody <dine...@wso2.com> > 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 : dine...@wso2.com | W : www.wso2.com >> >> On Tue, Dec 23, 2014 at 5:43 PM, Dinesh J Weerakkody <dine...@wso2.com> >> 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 : dine...@wso2.com | W : www.wso2.com >>> >> >> > > > -- > 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
