Yes it will be much more user-friendly, if we can allow the providers to
search and export.

In implementation POV we can use the functionality to export all APIs for a
providers etc .. by searching in a controlled manner.

e.g. calling a /export-all resource (by a provider) would call this search
and export functionality by setting the authenticated user as the provider.

On Tue, Jan 17, 2017 at 9:51 PM, Isuru Haththotuwa <isu...@wso2.com> wrote:

> Hi Rushmin/Uvindra,
>
> Thanks for the clarifications and inputs.
>
> Yes I agree that there is a valid use case for bulk import of APIs. This
> was suggested in a previous reply as well, by Jochen. I suggest we use the
> standard API search functionality to cater this, where we can use all the
> supported search criteria, provider, api name, wildcards, etc. WDYT?
>
> On Tue, Jan 17, 2017 at 6:12 PM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> I think there might be a valid case for allowing a provider to
>> export/import all the APIs that belong to that provider only in bulk. Its
>> much more user friendly as Rushmin has mentioned
>>
>> On 17 January 2017 at 17:15, Rushmin Fernando <rush...@wso2.com> wrote:
>>
>>> Hi Isuru,
>>>
>>> Please see my comments inline.
>>>
>>>
>>>
>>> On Wed, Jan 11, 2017 at 6:03 PM, Isuru Haththotuwa <isu...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 11, 2017 at 2:56 PM, Rushmin Fernando <rush...@wso2.com>
>>>> wrote:
>>>>
>>>>> IMO although we need bulk (all APIs) exporting and per API exporting,
>>>>> only one ReST resource is enough for importing.
>>>>>
>>>>> The resource would read the received package and import the API(s)
>>>>> inside the package. So having a ReST resource for importing a single API 
>>>>> is
>>>>> redundant.
>>>>>
>>>> Agreed. Should be able to identify whether there is only a single api /
>>>> many apis from the multipart data and do the API data insertion with a
>>>> single resource.
>>>>
>>>>>
>>>>> And is there a real need for restricting the bulk import for admin
>>>>> users ?
>>>>>
>>>> An API can be published by different users. In a scenario where the api
>>>> portal is exposed as a service (where users can signup and publish APIs),
>>>> IMHO we should restrict the ability for a single user to export/import all
>>>> APIs, which can impact all users.
>>>>
>>>>>
>>>>>
>>> Actually I was only commenting on API importing. Say I'm an API
>>> publisher and I have published 10 APIs. I should be able to export all 10
>>> APIs and import them to another env.
>>>
>>> Seems like we need a generic bulk API import/exports as well as *ALL*
>>> API import/export which is a special case and a more restricted action.
>>>
>>>
>>>
>>>> On Tue, Jan 10, 2017 at 11:22 AM, Isuru Haththotuwa <isu...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Devs,
>>>>>>
>>>>>> This is to discuss subject.
>>>>>>
>>>>>> *Requirement:*
>>>>>>
>>>>>> Once an API is exported, its possible to be directly imported in to
>>>>>> another APIM deployment in a separate environment. For an admin user, it
>>>>>> should be possible to export all APIs in one deployment to another one.
>>>>>>
>>>>>> The following information will be available in exported data, related
>>>>>> to a single API:
>>>>>>
>>>>>>    - Docs
>>>>>>    - API definition (JSON formatted)
>>>>>>    - Swagger file (JSON formatted)
>>>>>>    - Gateway configuration
>>>>>>    - API thumbnails (image)
>>>>>>
>>>>>> Several new resources will be added to the publisher rest API to
>>>>>> cater this, as follows:
>>>>>>
>>>>>> *GET **/apis/{apiId}**/export-config*
>>>>>>
>>>>>>    - Produces a form/multipart output as a zip archive, which will
>>>>>>    have the following structure and which will comprise of the above 
>>>>>> mentioned
>>>>>>    items:
>>>>>>
>>>>>> *          <provider-name>-<api-name>-<*
>>>>>>
>>>>>> *api-version>.zip                    |*
>>>>>>
>>>>>>
>>>>>> *                    | --- Docs                    |        |*
>>>>>> *                    |        | --- *<documentation_id>
>>>>>>                    * |  *
>>>>>> * |*
>>>>>> *                    |                        | ---* documentation
>>>>>> metadata (json)
>>>>>>                   *  |                        | ---* documentation
>>>>>> content (optional)
>>>>>>
>>>>>> *                    |*
>>>>>>
>>>>>>
>>>>>> *                    | --- Gateway-Config                    |
>>>>>>              |*
>>>>>> *                    |              | --- *gateway config file
>>>>>>
>>>>>> *                    |*
>>>>>> *                    | --- *thumbnail file
>>>>>>
>>>>>> *                    |*
>>>>>> *                    | --- *api definition (json)
>>>>>>
>>>>>> *                    |*
>>>>>> *                    | --- *swagger definition (json)
>>>>>>
>>>>>>
>>>>>> Note that there can be multiple docs for a single API.
>>>>>>
>>>>>> *GET **/apis/export-config*
>>>>>>
>>>>>>    - Produces a zip archive comprising of the above structure for
>>>>>>    each API in the system. This operation will be permitted for admin 
>>>>>> users
>>>>>>    only.
>>>>>>
>>>>>>
>>>>>> *POST **/apis**/{apiId}**/import-config*
>>>>>>
>>>>>>    - Consumes the same zip archive produced by the
>>>>>>    /{apiId/}export-config resource as a form/multipart input, extracts 
>>>>>> and
>>>>>>    inserts the relevant data.
>>>>>>
>>>>>>
>>>>>> *POST *
>>>>>> */apis/import-config*
>>>>>>
>>>>>>    - Consumes the same zip archive produced by the /export-config
>>>>>>    resource as a form/multipart input, extracts and inserts the relevant 
>>>>>> data
>>>>>>    for all APIs. Should be permitted only for admin users.
>>>>>>
>>>>>>
>>>>>> This does not consider the endpoint information [1] yet. Would need
>>>>>> to incorporate that here in a suitable way.
>>>>>>
>>>>>> Please share your feedback.
>>>>>>
>>>>>> [1]. [Architecture] [APIM][C5] - Definining Endpoint for Resource
>>>>>> from Rest API
>>>>>>
>>>>>> --
>>>>>> Thanks and Regards,
>>>>>>
>>>>>> Isuru H.
>>>>>> +94 716 358 048 <071%20635%208048>* <http://wso2.com/>*
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Best Regards*
>>>>>
>>>>> *Rushmin Fernando*
>>>>> *Technical Lead*
>>>>>
>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>>>>
>>>>> mobile : +94775615183
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks and Regards,
>>>>
>>>> Isuru H.
>>>> +94 716 358 048 <071%20635%208048>* <http://wso2.com/>*
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Best Regards*
>>>
>>> *Rushmin Fernando*
>>> *Technical Lead*
>>>
>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>>
>>> mobile : +94775615183
>>>
>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 777733962
>>
>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>*
>
>
>


-- 
*Best Regards*

*Rushmin Fernando*
*Technical Lead*

WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware

mobile : +94775615183
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to