On Fri, Mar 1, 2019 at 10:49 AM Amali Matharaarachchi <ama...@wso2.com> 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 <nad...@wso2.com> 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 <nuw...@wso2.com> 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 <ama...@wso2.com> >>> 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 <ama...@wso2.com> >>>> wrote: >>>> >>>>> Adding architecture@wso2.org >>>>> >>>>> On Fri, Feb 22, 2019 at 11:08 AM Amali Matharaarachchi < >>>>> ama...@wso2.com> 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) nuw...@wso2.com >>> [image: Signature.jpg] >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
