Hi, On Wed, Aug 3, 2016 at 9:54 AM, Thilini Cooray <[email protected]> wrote:
> Hi Janaka, > > > On Tue, Aug 2, 2016 at 5:43 PM, Janaka Ranabahu <[email protected]> wrote: > >> Hi Malintha, Kaveesha, >> >> On Fri, Jul 22, 2016 at 3:29 PM, Malintha Amarasinghe <[email protected] >> > wrote: >> >>> >>> >>> On Fri, Jul 22, 2016 at 3:25 PM, Malintha Amarasinghe < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> +1 for this improvement as it will make the developer's life easy when >>>> exporting/importing multiple APIs. >>>> >>>> The option [2] is better in situations like there are many APIs to bulk >>>> export so that the it might be difficult for a user to specify each and >>>> every APIs to export: what he wants is simply export all the APIs >>>> available. The overhead of the API call is not significant IMHO; there will >>>> be only one (or very few) additional calls to getAllAPIs. >>>> >>>> But as we discussed offline, we can start from step [1], and then >>>> improve it by adding step [2]. >>>> >>> Step 1: CSV file with list of API name/version/provider --> Bulk export >>> Step 2: call getAllApis() and get the list of APIs --> Generates the CSV >>> file (we can implement this as a different operation and then provide the >>> generated CSV file as an input to Step1) >>> >> Do we really have a use-case where a customer has to import/export all >> the APis in a environment. It is highly unlikely that this would happen. >> IMO, we should only support the file based approach. That would be >> sufficient for the bulk import/export purposes. >> > > What if a user decides to move from one environment to another (from Dev > to QA or on-premise to API Cloud etc.) and wants to move all his deployed > APIs to the new environment? > If he has a huge number of APIs, IMO it would not be easy to name them one > by one on a file. Rather it would be easy if we have an option to export > and import as a whole. > > I too agree that this is not a first priority use case for the tool that > we need to address, however IMO this is something better to have. > Agreed. Then we do not have to call getAllApis() and create a CSV out of that. Just sending a query parameter saying all APIs would be sufficient right? Thanks, Janaka > > WDYT? > > Thanks, > ThiliniC. > > > >> >> Thanks, >> Janaka >> >>> >>> >>> Regarding the file format I would prefer CSV as it would make it easy to >>>> edit if need using existing tools. WDYT? >>>> >>>> Thanks! >>>> >>>> On Fri, Jul 22, 2016 at 10:58 AM, Kaveesha Perera <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I'm planing to improve APIM import/export tool to support bulk import >>>>> and bulk export of APIs. >>>>> >>>>> When considering the bulk export, there it came up to a discussion >>>>> point on how to get the API list to be export. Considering several facts, >>>>> came up with two suggestions as follows. >>>>> >>>>> [1]. Asking user to submit a file with explicitly written list of >>>>> APIs. (API detail may include name, version and provider) >>>>> >>>>> [2]. Getting the prevailing list of APIs using getAllAPIs REST API, >>>>> save the usable content of resulting string in a separate file, then allow >>>>> user to edit it such that he can remove the unwanted APIs from the list, >>>>> use it as a input for the bulk export. >>>>> >>>>> Currently we prefer procedure [1], since the process [2] creates >>>>> additional overhead due to the REST API call. Still there can be are pros >>>>> and cons in both the processors. If any opinions on above and any options >>>>> please do reply. >>>>> >>>>> Regards. >>>>> -- >>>>> Kaveesha Perera >>>>> Intern - Software Engineering >>>>> >>>>> mobile: 0716130471 >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >>> >>> >> >> >> -- >> *Janaka Ranabahu* >> Associate Technical Lead, WSO2 Inc. >> http://wso2.com >> >> >> *E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 >> <%2B94%20718370861>* >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Best Regards, > > *Thilini Cooray* > Software Engineer > Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194> > E-mail : [email protected] > > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Janaka Ranabahu* Associate Technical Lead, WSO2 Inc. http://wso2.com *E-mail: [email protected] <http://wso2.com>**M: **+94 718370861* Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
