Re: [Architecture] [APIM] [3.0] Publishing to External Stores via Publisher REST APIs
With this change we have to perform a release to the CLI tool and maintain
the both versions of CLI tool to support old product versions and later
versions. Let's track those changes as well.
On Thu, Aug 15, 2019 at 3:12 PM Malintha Amarasinghe
wrote:
>
>
> On Thu, Aug 15, 2019 at 9:03 AM Ishara Cooray 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=true -F
> file={@api.zip} *
> Then: Same request :: Updates the existing API
> *POST /import/api?preserveProvider=true=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
>> 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}={providerName}*
>>>
>>> *curl -H "Authorization:Basic YWRtaW46YWRtaW4=" -X GET
>>> "https://localhost:9443/api/am/admin/v0.14/export/api?name=PizzaShackAPI=1.0.0=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
>>> "
>>> -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]
>>>
Re: [Architecture] [APIM] [3.0] Publishing to External Stores via Publisher REST APIs
On Thu, Aug 15, 2019 at 9:03 AM Ishara Cooray 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=true -F
file={@api.zip} *
Then: Same request :: Updates the existing API
*POST /import/api?preserveProvider=true=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
> 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}={providerName}*
>>
>> *curl -H "Authorization:Basic YWRtaW46YWRtaW4=" -X GET
>> "https://localhost:9443/api/am/admin/v0.14/export/api?name=PizzaShackAPI=1.0.0=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
>> "
>> -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
>> wrote:
>>
>>>
>>>
Re: [Architecture] [APIM] [3.0] Publishing to External Stores via Publisher REST APIs
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
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}={providerName}*
>
> *curl -H "Authorization:Basic YWRtaW46YWRtaW4=" -X GET
> "https://localhost:9443/api/am/admin/v0.14/export/api?name=PizzaShackAPI=1.0.0=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
> "
> -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
> wrote:
>
>>
>>
>> On Tue, Aug 6, 2019 at 9:35 PM Dushani Wellappili
>> 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
Re: [Architecture] [APIM] [3.0] Publishing to External Stores via Publisher REST APIs
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}={providerName}*
*curl -H "Authorization:Basic YWRtaW46YWRtaW4=" -X GET
"https://localhost:9443/api/am/admin/v0.14/export/api?name=PizzaShackAPI=1.0.0=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
"
-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
wrote:
>
>
> On Tue, Aug 6, 2019 at 9:35 PM Dushani Wellappili
> 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
Re: [Architecture] [APIM] [3.0] Publishing to External Stores via Publisher REST APIs
On Tue, Aug 6, 2019 at 9:35 PM Dushani Wellappili 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
