Hi,
Thank you for your suggestions. The current implementation is as follows.
*Initial configuration file (*toolkit-config.toml file*)*:
[token]
# REST version is mapped to a particular API manager version. Please find
the summary of APIM version to REST version mapping below;
# APIM 2.5.0 -> v0.13
# APIM 2.6.0 -> v0.14
# APIM 2.6.1 -> v0.14
restVersion = "v0.14"
publisherEndpoint = "{baseURL}/api/am/publisher/{restVersion}"
adminEndpoint = "{baseURL}/api/am/admin/{restVersion}"
registrationEndpoint =
"{baseURL}/client-registration/{restVersion}/register"
tokenEndpoint = "{baseURL}/oauth2/token"
*Commands*
1.
Execute
./micro-gw setup pizzashack-project -a PizzaShackAPI -v 1.0.0
> Enter Username:
admin
> Enter Password for admin:
****
> Enter APIM base URL [https://localhost:9443/]:
.
.
.
Then the toolkit-config file will look similar to the following (Note: {
baseURL} will be replaced according to the user input):
[token]
#REST version is mapped to a particular API manager version. Please find
the summary of APIM version to REST version mapping below;
# APIM 2.5.0 -> v0.13
# APIM 2.6.0 -> v0.14
# APIM 2.6.1 -> v0.14
restVersion = "v0.14"
publisherEndpoint = "https://localhost:9443/api/am/publisher/{restVersion}";
adminEndpoint = "https://localhost:9443/api/am/admin/{restVersion}";
registrationEndpoint = "
https://localhost:9443/client-registration/{restVersion}/register";
tokenEndpoint = "https://localhost:9443/oauth2/token";
2. Execute
./micro-gw reset
Then the toolkit-config file will revert back to:
[token]
#REST version is mapped to a particular API manager version. Please find
the summary of APIM version to REST version mapping below;
# APIM 2.5.0 -> v0.13
# APIM 2.6.0 -> v0.14
# APIM 2.6.1 -> v0.14
restVersion = "v0.14"
publisherEndpoint = "{baseURL}/api/am/publisher/{restVersion}"
adminEndpoint = "{baseURL}/api/am/admin/{restVersion}"
registrationEndpoint =
"{baseURL}/client-registration/{restVersion}/register"
tokenEndpoint = "{baseURL}/oauth2/token"
I would really appreciate your feedback. Thank you.
On Mon, Mar 4, 2019 at 7:30 PM Naduni Pamudika <[email protected]> wrote:
> On Fri, Mar 1, 2019 at 9:37 PM Rajith Roshan <[email protected]> wrote:
>
>> Hi,
>> What if we change the config as below[1]. We only keep the rest version
>> and add a detail comment in the config on how to derive REST version from
>> APIM version. Rather than doing this logic in code level(hard code for
>> known versions), by hiding the conversion to the user will makes it harder
>> for the user to understand the behavior. This might give understanding that
>> one APIM version can be used with multiple rest API versions (i.e user
>> might be using APIM 2.5.0 but he might think he can use rest version
>> v0.14(with APIM 2.5.0) which is APIM 2.6.0, rest version).
>> Adding a detail comment in the config seems more appropriate rather than
>> deriving rest version on our own and asking user to specify it when ever we
>> can not derive it.
>>
>>
>> [1]-
>> #rest version is mapped to particular API manager version. Please find
>> the summary of APIM version to REST version mapping below
>> # APIM 2.5.0 -> v0.13
>> # APIM 2.6.0 -> v0.14
>> restVersion = v0.14
>> publisherEndpoint = "https://localhost:9443/api/am/publisher/{
>> <https://localhost:9443/api/am/publisher/%7Bversion%7D>restVersion}
>> <https://localhost:9443/api/am/publisher/%7Bversion%7D>"
>> adminEndpoint = "https://localhost:9443/api/am/admin/{
>> <https://localhost:9443/api/am/admin/%7Bversion%7D>restVersion}
>> <https://localhost:9443/api/am/admin/%7Bversion%7D>"
>> registrationEndpoint = "https://localhost:9443/client-registration/{
>> <https://localhost:9443/client-registration/%7Bversion%7D/register>
>> restVersion}/register
>> <https://localhost:9443/client-registration/%7Bversion%7D/register>"
>>
>> +1 for this. This will minimise most of the redo work in each new
> microgateway release, due to updating the mappings in the code level.
> Rather than keeping two configs for the APIM version and the REST API
> version, keeping only one config will simplify the work from both the user
> and the developer point of views.
>
> Thanks,
> Naduni
>
>> On Fri, Mar 1, 2019 at 2:45 PM Naduni Pamudika <[email protected]> wrote:
>>
>>> On Fri, Mar 1, 2019 at 10:49 AM Amali Matharaarachchi <[email protected]>
>>> wrote:
>>>
>>>> I think apimVersion should always have a value. Each release should
>>>>> have its default.
>>>>>
>>>>> restVersion only comes in handy if we want to use a microgateway with
>>>>> an APIM version that was released after the microgateway was released.
>>>>> This
>>>>> is the only use case where we will not know how to derive the Rest API
>>>>> version from the respective APIM version.
>>>>>
>>>>
>>>> Noted. Thank you.
>>>>
>>>> How are we going to derive the Rest API version? Do we keep a mapping
>>>>> between the APIM version and the Rest API version in the microgateway code
>>>>> level? If so, do not we need to modify the microgateway code after each
>>>>> APIM release?
>>>>>
>>>>
>>>> Yes. We keep a map for APIM and REST version. In the case of a new APIM
>>>> release, it is not a must to update that mapping, since we give the user
>>>> the flexibility to mention the REST version manually. However, if we can
>>>> update the map after each new APIM release it is more desired. But I am
>>>> afraid it is not practical.
>>>>
>>>> Yes it would be great if we can do this after each APIM release, my
>>> concern also was how practical that is. At least we can consider updating
>>> the mapping in new microgateway releases. For the new APIM releases, if we
>>> are not going to update the microgateway mapping, then we need to clearly
>>> mention that in the docs. Otherwise, the users will get confuse as they
>>> expect the same behaviour for all the APIM releases.
>>>
>>> Thanks,
>>> Naduni
>>>
>>>> If we only have the Rest API version in the config file, we can ask the
>>>>> user to provide the respective Rest API version by providing a guide in
>>>>> the
>>>>> docs, so that we only have to modify the docs. Here we do not have to
>>>>> change the mapping/validation all the time. WDYT?
>>>>>
>>>>
>>>> Exactly.
>>>>
>>>> Initially the toolkit-config.toml file will have values of the current
>>>> APIM version and REST version in default. If the user specifically changed
>>>> it to another REST version, this new value will be considered.
>>>>
>>>> Thank you.
>>>>
>>>> On Fri, Mar 1, 2019 at 10:24 AM Naduni Pamudika <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Amali,
>>>>>
>>>>> How are we going to derive the Rest API version? Do we keep a mapping
>>>>> between the APIM version and the Rest API version in the microgateway code
>>>>> level? If so, do not we need to modify the microgateway code after each
>>>>> APIM release?
>>>>>
>>>>> If we only have the Rest API version in the config file, we can ask
>>>>> the user to provide the respective Rest API version by providing a guide
>>>>> in
>>>>> the docs, so that we only have to modify the docs. Here we do not have to
>>>>> change the mapping/validation all the time. WDYT?
>>>>>
>>>>> Thanks,
>>>>> Naduni
>>>>>
>>>>> On Fri, Mar 1, 2019 at 10:17 AM Nuwan Dias <[email protected]> wrote:
>>>>>
>>>>>> I think apimVersion should always have a value. Each release should
>>>>>> have its default.
>>>>>>
>>>>>> restVersion only comes in handy if we want to use a microgateway with
>>>>>> an APIM version that was released after the microgateway was released.
>>>>>> This
>>>>>> is the only use case where we will not know how to derive the Rest API
>>>>>> version from the respective APIM version.
>>>>>>
>>>>>> On Fri, Mar 1, 2019 at 10:08 AM Amali Matharaarachchi <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>> This email is regarding the implementation of the solution to the
>>>>>>> coupling issue in MicroGateway.
>>>>>>>
>>>>>>>
>>>>>>> Now the toolkit-config.toml will look similar to the following:
>>>>>>>
>>>>>>> apiMVersion = ""
>>>>>>> restVersion = ""
>>>>>>> publisherEndpoint = "
>>>>>>> https://localhost:9443/api/am/publisher/{version}";
>>>>>>> adminEndpoint = "https://localhost:9443/api/am/admin/{version}";
>>>>>>> registrationEndpoint = "
>>>>>>> https://localhost:9443/client-registration/{version}/register";
>>>>>>>
>>>>>>> A user can include either API Manager version (apiMVersion) or REST
>>>>>>> version (restVersion). If only the API Manager version is provided,
>>>>>>> we use predefined constant REST version for the provided API Manager
>>>>>>> version in the code.
>>>>>>>
>>>>>>> Furthermore, when we try to invoke API, The response we receive from
>>>>>>> API Manager can include extra properties that Microgateway is not aware
>>>>>>> of.
>>>>>>> In this case, we simply ignore such properties when parsing to objects
>>>>>>> in
>>>>>>> the Microgateway side.
>>>>>>>
>>>>>>> Thank you
>>>>>>>
>>>>>>> On Fri, Feb 22, 2019 at 3:49 PM Amali Matharaarachchi <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Adding [email protected]
>>>>>>>>
>>>>>>>> On Fri, Feb 22, 2019 at 11:08 AM Amali Matharaarachchi <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I am working on reducing coupling between APIM and
>>>>>>>>> Microgateway[1].
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Problem*:
>>>>>>>>>
>>>>>>>>> Microgateway requires the same version of the API Manager to be
>>>>>>>>> executed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Description*:
>>>>>>>>>
>>>>>>>>> API Manager uses URI versioning for its REST API. Microgateway
>>>>>>>>> uses this REST API, so it needs to consider the version. Microgateway
>>>>>>>>> is
>>>>>>>>> coupled with its same version of API Manager due to a declaration of
>>>>>>>>> these
>>>>>>>>> REST URLs as constants. See below example.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Example*:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> * API Manager 2.5.0
>>>>>>>>>
>>>>>>>>> version - 0.13.0
>>>>>>>>>
>>>>>>>>> * API Manager 2.6.0
>>>>>>>>>
>>>>>>>>> version - 0.14.0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Microgateway 2.6.0 cannot be executed with API Manager 2.5.0
>>>>>>>>> because Microgateway 2.6.0 has below REST service constants in
>>>>>>>>> "/product-microgateway/components/micro-gateway-cli/src/main/java/org/wso2/apimgt/gateway/cli/constants/RESTServiceConstants.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> public static final String PUB_RESOURCE_PATH =
>>>>>>>>> "/api/am/publisher/v0.14";
>>>>>>>>>
>>>>>>>>> public static final String PUB_CLIENT_CERT_PATH =
>>>>>>>>> "/api/am/publisher/v0.14/clientCertificates";
>>>>>>>>>
>>>>>>>>> public static final String ADMIN_RESOURCE_PATH =
>>>>>>>>> "/api/am/admin/v0.14";
>>>>>>>>>
>>>>>>>>> public static final String DCR_RESOURCE_PATH =
>>>>>>>>> "/client-registration/v0.14/register";
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> which are bounded to API Manager 2.6.0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Solution*:
>>>>>>>>>
>>>>>>>>> Furthermore, there is a toolkit-config.toml file to setup
>>>>>>>>> configurations. We can avoid above constants by specifying these URLs
>>>>>>>>> as
>>>>>>>>> below in that file.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> publisherEndpoint = "https://localhost:9443/api/am/publisher/v0.13
>>>>>>>>> "
>>>>>>>>>
>>>>>>>>> adminEndpoint = "https://localhost:9443/api/am/admin/v0.13";
>>>>>>>>>
>>>>>>>>> registrationEndpoint = "
>>>>>>>>> https://localhost:9443/client-registration/v0.13/register";
>>>>>>>>>
>>>>>>>>> tokenEndpoint = "https://localhost:9443/oauth2/token";
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So a user can specify REST API version manually.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Suggested improvement:*
>>>>>>>>>
>>>>>>>>> Instead of specifying REST API version and these endpoints, allow
>>>>>>>>> the user to only add the API Manager version. The configuration file
>>>>>>>>> will
>>>>>>>>> include fields similar to the following.
>>>>>>>>>
>>>>>>>>> apimVersion = “2.5.0”
>>>>>>>>>
>>>>>>>>> publisherEndpoint = "https://localhost:9443/api/am/publisher/";
>>>>>>>>>
>>>>>>>>> adminEndpoint = "https://localhost:9443/api/am/admin/";
>>>>>>>>>
>>>>>>>>> registrationEndpoint = "
>>>>>>>>> https://localhost:9443/client-registration/{version}/register";
>>>>>>>>>
>>>>>>>>> tokenEndpoint = "https://localhost:9443/oauth2/token";
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Implementation:*
>>>>>>>>>
>>>>>>>>> In order to implement as above, we need to recognize the REST API
>>>>>>>>> version which corresponds to the API Manager version. Following
>>>>>>>>> approaches
>>>>>>>>> are identified;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1. Get the version of the REST API of the specific API Manager
>>>>>>>>> version by using the API Manager’s swagger definition. However, an
>>>>>>>>> endpoint
>>>>>>>>> to access swagger definition is not provided in API Manager 2.x
>>>>>>>>>
>>>>>>>>> 2. Profile REST API version for each API Manager version in
>>>>>>>>> Microgateway. (Drawback of this approach is that, Microgateway will
>>>>>>>>> only
>>>>>>>>> provide backward compatibility(compatible only to past API Manager
>>>>>>>>> versions) because new versions of API Manager which are released
>>>>>>>>> later may
>>>>>>>>> not be included yet in version profiling.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Among them, the second option is selected. Version profiling in
>>>>>>>>> Microgateway is more suited considering time constraints and
>>>>>>>>> simplicity.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I would really appreciate your feedback. Thank you.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Reference:*
>>>>>>>>>
>>>>>>>>> [1] https://github.com/wso2/product-microgateway/issues/301
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Amali Lakshika*
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Software EngineerWSO2 Inc.: https://wso2.com
>>>>>>>> <http://wso2.com/>lean.enterprise.middle-waremobile: **+94 71 932
>>>>>>>> 1861*
>>>>>>>>
>>>>>>>> *skype: amali.94d*
>>>>>>>>
>>>>>>>> <http://wso2.com/signature>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Amali Lakshika*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Software EngineerWSO2 Inc.: https://wso2.com
>>>>>>> <http://wso2.com/>lean.enterprise.middle-waremobile: **+94 71 932
>>>>>>> 1861*
>>>>>>>
>>>>>>> *skype: amali.94d*
>>>>>>>
>>>>>>> <http://wso2.com/signature>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Nuwan Dias* | Director | WSO2 Inc.
>>>>>> (m) +94 777 775 729 | (e) [email protected]
>>>>>> [image: Signature.jpg]
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> [email protected]
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Naduni Pamudika*
>>>>> Senior Software Engineer | WSO2
>>>>>
>>>>> Mobile: +94 719 143658 <+94%2071%20914%203658>
>>>>> LinkedIn: https://lk.linkedin.com/in/naduni-pamudika
>>>>> Blog: https://medium.com/@naduni_pamudika
>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Amali Lakshika*
>>>>
>>>>
>>>>
>>>>
>>>> *Software EngineerWSO2 Inc.: https://wso2.com
>>>> <http://wso2.com/>lean.enterprise.middle-waremobile: **+94 71 932 1861*
>>>>
>>>> *skype: amali.94d*
>>>>
>>>> <http://wso2.com/signature>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Naduni Pamudika*
>>> Senior Software Engineer | WSO2
>>>
>>> Mobile: +94 719 143658 <+94%2071%20914%203658>
>>> LinkedIn: https://lk.linkedin.com/in/naduni-pamudika
>>> Blog: https://medium.com/@naduni_pamudika
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> *Rajith Roshan* | Senior Software Engineer | WSO2 Inc.
>> (m) +94-717-064-214 | (e) [email protected] <[email protected]>
>>
>> <https://wso2.com/signature>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Naduni Pamudika*
> Senior Software Engineer | WSO2
>
> Mobile: +94 719 143658 <+94%2071%20914%203658>
> LinkedIn: https://lk.linkedin.com/in/naduni-pamudika
> Blog: https://medium.com/@naduni_pamudika
> [image: http://wso2.com/signature] <http://wso2.com/signature>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
--
*Amali Lakshika*
*Software EngineerWSO2 Inc.: https://wso2.com
<http://wso2.com/>lean.enterprise.middle-waremobile: **+94 71 932 1861*
*skype: amali.94d*
<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
