On Thu, Aug 15, 2019 at 9:03 AM Ishara Cooray <isha...@wso2.com> wrote:

> 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}*
>
> When we use PUT */import/api *it implies that we do an update to the
resource which is identified in that resource path "import/api". In that
sense, it doesn't seem to give a proper meaning by Updating "/import/api"
resource as it doesn't identify which API we are going update.

Using POST we can do different operations that don't comply with usual REST
verbs with verb-resource included in resource path. For example The POST
"/import" here. And also: POST /copy, POST /merge etc are examples.

IMHO, import/api needs to be changed as "import-api".

The "overwrite" option simplifies the usages as well as we can use the same
request for creating and updating it later. Otherwise, the users need to
perform two different operations for creating the API very first time and
updating it (which requires to validate the existence of the API beforehand
which might need another API call).

First*:* Creates the API first time
*POST /import/api?preserveProvider=true&overwrite=true  -F
file={@api.zip}  *
Then: Same request :: Updates the existing API
*POST /import/api?preserveProvider=true&overwrite=true  -F
file={@updated-api.zip} *

WDYT?

Thanks!

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 <dusha...@wso2.com>
> 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
>> 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
>>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
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

Reply via email to