Hi Jochen, Apologies for the delayed response.
On Thu, Jan 19, 2017 at 10:14 PM, Jochen Traunecker < [email protected]> wrote: > Hi, > > it should be an optional parameter to define the “creator” of an API > during import (on behalf of feature). This is of importance especially when > importing is done by a technical user. If the “creator” user is not > available in the import environment the import operation will fail. > Makes sense. To handle the scenario where a creator of an API is not available in import environment, IMO we can provide an option to update the creator to the importer. WDYT? > > The log files / audit trail should reflect the “on behalf of” option, too. > “API XYZ imported by ADMIN with Creator = Homer”. > +1 > > Same applies to other operations (out of scope of export / import) like > “published by” and so on. > Agreed. Any piece of data bound to a user of the environment should be updated to fit the import environment. > > Thanks, > Jochen > > -- > Jochen Traunecker > > On 19 January 2017 at 07:11:30, Shani Ranasinghe ([email protected]) wrote: > > Hi Isuru, > > When we import an API, in the new environment, who will be listed as the > API creator? the person who imports it? that is if the user store is not > the same ? > > > On Wed, Jan 18, 2017 at 3:35 PM, Malintha Amarasinghe <[email protected]> > wrote: > >> 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 <+94%2071%20238%203306> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks and Regards > *, Shani Ranasinghe* > Senior Software Engineer > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 77 2273555 <+94%2077%20227%203555> > Blog: http://waysandmeans.blogspot.com/ > linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks and Regards, Isuru H. +94 716 358 048* <http://wso2.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
