Hi all, After we decided to go ahead with the import-export approach, we decided to move the existing api-import-export APIs to Admin REST APIs (similar to current application-import-export APIs). So the Admin REST API will have the following two new resources.
*GET /export/api?name={APIName}&version={version}&providerName={providerName}* *curl -H "Authorization:Basic YWRtaW46YWRtaW4=" -X GET "https://localhost:9443/api/am/admin/v0.14/export/api?name=PizzaShackAPI&version=1.0.0&providerName=admin <https://localhost:9443/api/am/admin/v0.14/export/api?name=PizzaShackAPI&version=1.0.0&providerName=admin>" -k > exportAPI.zip -i* *POST /import/api?preserveProvider={false} -F file={@api.zip}* *curl -H "Authorization:Basic YWRtaW5AYWJjLmNvbTphZG1pbg==" -F file=@PizzaShackAPI-1.0.0.zip -X POST "https://localhost:9443/api/am/admin/v0.14/import/api?preserveProvider=false <https://localhost:9443/api/am/admin/v0.14/import/api?preserveProvider=false>" -k -i* Recently we have added another new resource "*PUT /{apiID}**?preserveProvider={false} -F file={@api.zip}**"* to the current api-import-export webapp to update an existing API by given API ID (AFAIK we have added it to support the CI/CD flow). We need to move the same to new Admin api-import-export REST APIs as well. However, it does not seems right to define the resource as "*PUT update/{apiID}**?preserveProvider={false} -F file={@api.zip}"*. We can move the same functionality to the "*POST /import/api?preserveProvider={false} -F file={@api.zip}*" API with another optional query parameter "*isOverwrite*" to update an existing API. Instead of giving the APIID to update, can't we get the existing API using the name, version, and tenantDomain of the logged-in user? We already have an APIUtil method to retrieve an API using the above three arguments [1]. Would this break the story of updating APIs in CI/CD flow? Appreciate your thoughts in moving forward. [1] https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/utils/APIUtil.java#L6798 Thanks *Dushani Wellappili* Software Engineer - WSO2 Email : dusha...@wso2.com Mobile : +94779367571 Web : https://wso2.com/ On Wed, Aug 7, 2019 at 6:32 PM Malintha Amarasinghe <malint...@wso2.com> wrote: > > > On Tue, Aug 6, 2019 at 9:35 PM Dushani Wellappili <dusha...@wso2.com> > wrote: > >> Hi all, >> >> When publishing to external stores, at runtime we need to use API create, >> life-cycle change, create a version, add API thumbnail, delete Publisher >> REST APIs. In order to create the API payload, we need to do the mapping >> from API object to APIDTO. Reusing the existing APIDTO or APIMappingUtil >> classes are not possible as we do not import rest.api dependencies to impl >> level. Creating the payload manually from scratch will not be a very >> cleaner approach, also we will be duplicating the same logic. >> >> Hence following are the options which might help us to achieve this. >> >> - Generate a REST client using publisher REST API swagger (using >> openapi-generator plugin) and pack it as a jar in the product (packing the >> component inside service-stubs). But for that, we need to pack an >> additional set of dependencies to lib as well. For example, the generated >> client is using okhttp client. We also need to add the APIMappingUtil >> logic >> (to map API to DTO) as util class inside the same client. >> >> >> - Generate only the DTO classes using publisher REST API swagger and >> pack it as a jar in service-stubs. However, even in this case, API to DTO >> object mapping will need to be defined separately in the same service >> client. Conversion from DTO to JSON and invoking the HTTP client need to >> be >> handled in WSO2APIPublisher code. >> >> >> - Use import-export webapp, to import the API and modify the api.json >> to include the artifact properties apiOwner, advertiseOnly, redirectURL, >> zip, and export it to the external Store. A separate REST API call to >> change the lifecycle of the API to "Published" state, needs to be done. >> >> +1 for doing import/export due to the simpleness and efficientness > compared to using Publisher's /apis REST API for creating/updating the API. > We can get extra advantages with supporting documents as well. Earlier we > didn't support it and we automatically get the benefit by using > import/export. > > >> One of the main drawbacks of the first two options is maintaining the >> DTO, Mapping logic in two different places whenever we do a change to the >> REST API. Appreciate your response on this regard. >> >> Thanks >> >> *Dushani Wellappili* >> Software Engineer - WSO2 >> >> Email : dusha...@wso2.com >> Mobile : +94779367571 >> Web : https://wso2.com/ >> >> >> > > -- > Malintha Amarasinghe > *WSO2, Inc. - lean | enterprise | middleware* > http://wso2.com/ > > Mobile : +94 712383306 >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture