Hi Dinesh, 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] > > 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. > > 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. > When storing the context in APIM DB, I think you have to keep the resolved context not the structure of the context. Having the resolved context in AM_API table will allow validating the key with a single SQL. As you have identified, it would be enough to keep the structure of the context only in RXT. No additional columns are needed on AM_API table. > > > > > 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 >> > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
