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. 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
