Hi Jochen, 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. 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 I believe this should cover differentiating between the actual owner of the API and the person who did the creating on a given environment. On 23 January 2017 at 08:47, Isuru Haththotuwa <[email protected]> wrote: > HI Shani, > > Apologies for the late response. > > On Thu, Jan 19, 2017 at 11:40 AM, 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 ? >> > In import export we have not yet considered data changes; meaning whatever > is exported will be imported as it is. So if the provider needs to be > changed, +1 to set it to the importer. > >> >> >> 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 >> >> > > > -- > Thanks and Regards, > > Isuru H. > +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>* > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
