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
[email protected] -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 : [email protected]
Mobile : +94779367571
Web : https://wso2.com/
On Wed, Aug 7, 2019 at 6:32 PM Malintha Amarasinghe <[email protected]>
wrote:
>
>
> On Tue, Aug 6, 2019 at 9:35 PM Dushani Wellappili <[email protected]>
> 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 : [email protected]
>> Mobile : +94779367571
>> Web : https://wso2.com/
>>
>>
>>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
