Hi,
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?
Mentioned util method returns the provider name , but not the apiId.
IMO correct approach to update an api artifact is to have the* PUT *method
rather than having an option in the POST method.
Where we can have
*PUT /import/api?preserveProvider={false} -F file={@api.zip}*
we can obtain the apiId as below .
1. get the provider name from the above suggested util method.
APIUtil.getAPIProviderFromAPINameVersionTenant
2. Create an APIIdentifier
APIIdentifier apiIdentifier = new APIIdentifier(providerName, apiName,
apiVersion);
3. Obtain apiId.
int apiId = ApiMgtDAO.getInstance().getAPIID(apiIdentifier, null);
Thanks & Regards,
Ishara Udeshika Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
On Wed, Aug 14, 2019 at 11:19 AM Dushani Wellappili <[email protected]>
wrote:
> 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
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
