Hi, Yes +1 from me too. Additionally, if we can support exporting a specific set of APIs at once by giving a list of UUIDs or a provider-name-version based list that would also be useful and it can save multiple HTTP requests when we need to download a very specific set of APIs. That requirement was considered when writing the CLI based import export tool.
Thanks! On Wed, Jan 18, 2017 at 1:09 PM, Uvindra Dias Jayasinha <[email protected]> wrote: > +1 Isuru, that would be extremely helpful I think. The search > functionality should respect user boundaries to ensure that APIs that > should not be visible to a given user don't get exported. > > On 17 January 2017 at 21:51, Isuru Haththotuwa <[email protected]> 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 <[email protected] >> > 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 <[email protected]> wrote: >>> >>>> Hi Isuru, >>>> >>>> Please see my comments inline. >>>> >>>> >>>> >>>> On Wed, Jan 11, 2017 at 6:03 PM, Isuru Haththotuwa <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jan 11, 2017 at 2:56 PM, Rushmin Fernando <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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/>* >> >> >> > > > -- > Regards, > Uvindra > > Mobile: 777733962 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Malintha Amarasinghe Software Engineer *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
