Re: [Architecture] Meeting Note : Implement a Pluggable Version Strategy feature in APIManager
Hi All,
Please find the implementation details of this.
The user has the ability to define the context by embedding the version
with the {version} param. If that is done, we resolve the {version} param
with the given version of the API. We store both the resolved context and
the context template in the RXT(this is to use when creating new versions
from an existing API)
Ex:- context -- {version}/foo
If the user doesn't give the {version} param, when adding the API, we
append the {version} param to the end of the context. This is to have a
similar behavior as the previous releases where the API URL was
.../{context}/{version}
With this change, in all the places we assume that the version is embedded
in the context and we have done the changes accordingly. At synapse level
all the API's has version-type as context
Please raise any issues you find with this approach.
Thanks,
Janaka
On Mon, Jan 26, 2015 at 1:04 PM, Dinesh J Weerakkody dine...@wso2.com
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 : dine...@wso2.com | W : www.wso2.com
On Thu, Jan 15, 2015 at 8:08 AM, Dinesh J Weerakkody dine...@wso2.com
wrote:
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
Re: [Architecture] Meeting Note : Implement a Pluggable Version Strategy feature in APIManager
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.
Re: [Architecture] Meeting Note : Implement a Pluggable Version Strategy feature in APIManager
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?
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 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 :
Re: [Architecture] Meeting Note : Implement a Pluggable Version Strategy feature in APIManager
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”
Re: [Architecture] Meeting Note : Implement a Pluggable Version Strategy feature in APIManager
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
