Here's my next dilemma: Should we make the API to GET/PUT these access policies all at one endpoint, or nest them as sub-resources under each viewset they control? I'm outlining the two options below, please reply with your thoughts.
Option "nested under each viewset". This would have each access policies live under the viewset it pairs with, e.g. the /pulp/api/v3/remotes/file/file/ would then have a sub-resource /pulp/api/v3/remotes/file/file/access_policy/ pros: it's simple for users cons: it's more complicated to develop because we have to try to automatically add this to lots of viewsets. Also it's complicated to see the policies all in one place. Also if there are other sub-resources that may want to use a name like "access_policy" this becomes a problem unless we allow plugin writers to "move" this resource to another area somehow. Option "all at one viewset". This would have all access policies live at /pulp/api/v3/access_policy/ with detail views like /pulp/api/v3/access_policy/:uuid/ pros: it avoids url conflicts described above. It's easy to implement, and you can see all the policies in one place cons: it requires users to "find" their access_policy and this could cause user mistakes also... What do you think we should do to create the best user experience first-and-foremost, and the best plugin writer experience second-most? Thanks! Brian On Tue, Jul 14, 2020 at 8:44 AM Tatiana Tereshchenko <ttere...@redhat.com> wrote: > +1 to idea 1 since the URLs seem to me more stable than class paths. We > should not change REST API much but potentially can refactor code in some > ways. > > One nitpick, maybe the `viewset` field should have a more generic name, > since we don't use viewsets exclusively, we also have separate views, e.g. > for orphan cleanup or status. > I don't have good ideas though... `endpoint`? (though it's not a full > endpoint), `guarded_view_obj`? `view_object`? `view`? :) > > On Tue, Jul 14, 2020 at 2:21 AM Dennis Kliban <dkli...@redhat.com> wrote: > >> Pulp 2 users would definitely be familiar with describing policies in >> terms of urls. The Pulp 3 REST API already uses the pulp_href field as the >> primary identifier. You should implement idea 1. >> >> On Mon, Jul 13, 2020, 5:45 PM Brian Bouterse <bmbou...@redhat.com> wrote: >> >>> I need some design input. To store AccessPolicy data in the DB I think >>> we want one Model where each instance is the access policy for a given >>> viewset. I think this would be better than one Model per Viewset which >>> would generate N tables for N viewsets with 1 instance of each which would >>> be very strange and inefficient. >>> >>> So let's assume we have a simple definition like the one below. Each >>> instance stores the policy for one viewset. >>> >>> class AccessPolicy(BaseModel): >>> data = JSONField() >>> >>> So what second field can I add to this that would allow me to relate an >>> instance of this model to a viewset. For example the FileRemoteViewset >>> here: >>> https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116 >>> >>> Idea 1: Add a viewset = CharField(). Have it store values as URLs, e.g. >>> /pulp/api/v3/remotes/file/file/. >>> Idea 2: Add a viewset = CharField(), and have it store values as >>> classpaths, e.g. 'pulp_file.app.viewsets.RemoteFileViewset'. >>> >>> I think Idea 1 makes the most sense because that's how our users think >>> of it. I can't think of a good alternative. What do you think makes the >>> most sense? What alternative ideas should we consider? >>> >>> If you have feedback please share it. I need to start into something to >>> get it going tomorrow even if it's just Idea 1 for lack of an alternate >>> proposal. >>> >>> Thanks, >>> Brian >>> _______________________________________________ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev