Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

By considering above discussion and the off line chat we had, it was concluded that, we allow the default resource to scope mapping remain in the Swagger doc and move whatever resource to scope mappings a user needs to deployment.yaml which is the global configuration file for the product. This

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

On 15 May 2017 at 14:41, Nuwan Dias wrote: > What is the benefit of using operationId instead of the resource path? In > the current Swagger we do not have operationIds defined right? > Since it will be just a string, it is less error prone than defining the resource path and

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

If we are to avoid migration of modified scopes, I think we have to go with the second approach of defining resource to scope mapping in an optional config file. However, rather than defining the resource path in this file, how about using an unique identifier per operation? In swagger, we can

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

So it seems Sanjeewa's and my view points are clear on this. 1. Sanjeewa basically says let users (sys-admins) edit the Swagger file that define the product REST API. Objective is to avoid duplicating resource to scope mappings elsewhere. 2. I basically say maintain an optional config file so

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

No Sanjeewa, in the method I'm proposing the system "will not break" even if someone goes and puts Japanese characters in the config file. That is by design. One design principle from 3.0.0 onwards is to have no migration script involved. In the method I'm proposing we avoid migration 100% (for

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

On Tue, May 9, 2017 at 4:57 PM, Nuwan Dias wrote: > Regarding adding entries to the config file, you don't need to even open > the swagger file. What you need to do is to find the resource from the docs > and enter it into the config file. By expecting a sys admin to edit the >

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

Regarding adding entries to the config file, you don't need to even open the swagger file. What you need to do is to find the resource from the docs and enter it into the config file. By expecting a sys admin to edit the Swagger file my main worry is we're expecting the sys-admin to play with an

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

On Tue, May 9, 2017 at 12:59 PM, Nuwan Dias wrote: > > > On Tue, May 9, 2017 at 12:26 PM, Sanjeewa Malalgoda > wrote: > >> >> >> On Tue, May 9, 2017 at 11:52 AM, Nuwan Dias wrote: >> >>> There are several problems in allowing to edit the

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

On Tue, May 9, 2017 at 11:52 AM, Nuwan Dias wrote: > There are several problems in allowing to edit the Swagger file directly. > > 1. We change it on new product releases. So now users have to find a way > to merge whatever their changes when doing product upgrades. This is

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

There are several problems in allowing to edit the Swagger file directly. 1. We change it on new product releases. So now users have to find a way to merge whatever their changes when doing product upgrades. This is error prone. 2. The Swagger file is 100s of lines long and it has lots of

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

IMO its more like keep different representation of same data in different location. To edit/update optional place you suggested user anyway need to refer swagger file. So why don't we simply let users to edit it self without having another file? Thanks, sanjeewa. On Tue, May 9, 2017 at 11:01 AM,

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

On Tue, May 9, 2017 at 10:46 AM, Sanjeewa Malalgoda wrote: > > > On Tue, May 9, 2017 at 10:15 AM, Nuwan Dias wrote: > >> @Sanjeewa, if someone edits the Swagger file in conf, how do we ensure >> the next restart doesn't override that file? >> > If file exists

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

On Tue, May 9, 2017 at 10:15 AM, Nuwan Dias wrote: > @Sanjeewa, if someone edits the Swagger file in conf, how do we ensure the > next restart doesn't override that file? > If file exists it will not override else it will write to file system. If its containerized automated

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

@Sanjeewa, if someone edits the Swagger file in conf, how do we ensure the next restart doesn't override that file? The root cause of the problem here is that the "resource to scope" mapping is both a server configuration as well as it might be a user configuration when users want to find/corse

Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

On Mon, May 8, 2017 at 3:42 PM, Ishara Cooray wrote: > > > *Motivation:* > Before c5, API Manager product REST APIs resources have pre defined scopes > and they cannot be changed. > > But what if an admin needs to give access to Create, Update, Delete > actions to different

[Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.

*Motivation:* Before c5, API Manager product REST APIs resources have pre defined scopes and they cannot be changed. But what if an admin needs to give access to Create, Update, Delete actions to different users? if he can customize the scopes associated with each resource, then he will be able