HI Isuru, the two fields approach mentioned by Uvindra is IMHO the solution for the “on behalf of” requirement.. I added some remarks:
"Just to clarify we have two fields in the API table of the DB that we used to represent the API Owner and API creator as follows, PROVIDER - This is the actual owner of the API. This should not change during an Import since the ownership of a given API remains constant across all environments it maybe deployed on. *-> I agree, the PROVIDER will be in most use-cases the same identity in all environments. Still the same PROVIDER is not guaranteed to be around in all environments. By that there should be some means around to specify an arbitrary PROVIDER during import. * CREATED_BY - The person who actually created the API. Under normal circumstances this would be the same as the provider but in the case of an Import done by a operations user on behalf of someone when setting up an environment then that users name will be listed as CREATED_BY *+1* I believe this should cover differentiating between the actual owner of the API and the person who did the creating on a given environment." *+1* Thanks, Jochen On 26 January 2017 at 15:20:12, Isuru Haththotuwa ([email protected]) wrote: 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
