Yes, this was my point about option 1 being more RESTful. I’m not sure if you are arguing that <plugin> should also be plural. I believe it’s more of a namespace though like the “v3” part of our urls.
David On Tue, Apr 10, 2018 at 11:50 AM, Austin Macdonald <amacd...@redhat.com> wrote: > This change highlights a subtle related issue, which is the plurality of > endpoints. [0] > > *v3/content/<type>/* > > Here, the "type" seems to refer to the plugin, which is "file". This > implies the false assumption that there is only one content type per plugin. > > *v3/content/file/* > > The namespace plan highlights the problem. > > *v3/content/<plugin>/<type>/* > > The context is subtly shifted. The "plugin" is file, which is singular, > but the "type" refers to FileContent, which is an object and should be > plural. > > *v3/content/file/files/* > > [0]: https://docs.pulpproject.org/en/3.0/nightly/ > contributing/3.0-development/rest-api.html#rest-api-guidelines > > On Tue, Apr 10, 2018 at 11:38 AM, Austin Macdonald <amacd...@redhat.com> > wrote: > >> If ya'll don't mind leaving out v3/content/<plugin>/ endpoints, then I >> think we are all set. https://pulp.plan.io/issues/3472 should be ready >> to be groomed. Since I updated with the suggested implementation, would >> one of you mind marking it groomed? >> >> On Tue, Apr 10, 2018 at 9:03 AM, Austin Macdonald <amacd...@redhat.com> >> wrote: >> >>> >>> >>> On Tue, Apr 10, 2018 at 8:20 AM, David Davis <davidda...@redhat.com> >>> wrote: >>> >>>> I’m imagining v3/content/rpm/ returning all the content types for the >>>> rpm plugin (rpm, errata, package groups, etc) and thinking that will be >>>> very strange and awkward. >>>> >>> >>> Yes, that is what it would do. I don't know if anyone would need that, >>> my point was that the url structure would imply that you *could* make >>> this call. We don't currently implement v3/content though, so maybe this >>> isn't a big deal. >>> >>> >>>> >>>> David >>>> >>>> On Tue, Apr 10, 2018 at 8:13 AM, Dennis Kliban <dkli...@redhat.com> >>>> wrote: >>>> >>>>> On Mon, Apr 9, 2018 at 1:32 PM, Austin Macdonald <amacd...@redhat.com> >>>>> wrote: >>>>> >>>>>> I've updated the issue https://pulp.plan.io/issues/3472 to reflect >>>>>> the current consensus. >>>>>> >>>>>> However, I have some other points I'd like to discuss before we move >>>>>> on. >>>>>> >>>>>> *Implied endpoint:* >>>>>> v3/content/ansible/roles/ implies that there is a >>>>>> v3/content/ansible/. Even though this does not exist, it could, but it >>>>>> is a >>>>>> little awkward. >>>>>> >>>>> >>>>> I don't think this endpoint needs to exist. What use case does it >>>>> support? >>>>> >>>>> >>>>>> >>>>>> Implent v3/content/ansible/: >>>>>> >>>>>> 1. Create a model viewset and serializer for the ansible level: >>>>>> 1. class AnsibleContent(core.plugin.models.Content) >>>>>> 2. class AnsibleContentSerializer(core. >>>>>> plugin.serializers.ContentSerializer) >>>>>> 3. class AnsibleContentViewSet(core.plu >>>>>> gin.viewsets.ContentViewSet) >>>>>> 1. endpoint = "ansible" >>>>>> 2. Make the Role model, VS, and Serializer inherit from the >>>>>> AnsibleContent Model, VS, and Serializer >>>>>> >>>>>> The end result is that v3/content/ansible/ will return all Ansible >>>>>> content units, including Roles. v3/content/ansible/roles/ will only >>>>>> return >>>>>> Roles. >>>>>> >>>>>> *Publishers and Remotes* >>>>>> The above workflow makes sense and is useful if there are multiple >>>>>> units, but for the File plugin, this pattern adds an endpoint and 3 >>>>>> classes >>>>>> to the Content. If we want to be consistent and apply this to Remotes and >>>>>> Publishers, this is 3 useless endpoints and 9 extra classes. (These >>>>>> classes >>>>>> are simple, even if they are extraneous, conceptually) >>>>>> >>>>>> *IMO* >>>>>> I think we should document all of this in the plugin docs. For single >>>>>> type (and single remote, and single publisher) plugins, it will make more >>>>>> sense not to add an extra namespace. If we document how to add the extra >>>>>> namespace and when/why plugins should, that will be sufficient. Promoting >>>>>> consistency over simplicity in this case seems too far. >>>>>> >>>>>> *Or...* >>>>>> We could alter the Master/Detail code. I only have vague ideas about >>>>>> how to do this, but Master/Detail would essentially become >>>>>> Master/Plugin/Detail. This seems "right", but there isn't as much gain >>>>>> here >>>>>> as you might think. If we did it this, plugins would be required to >>>>>> namespace, and would be still be required to make all those extra >>>>>> classes. >>>>>> The only practical difference is that the AnsibleRoleViewSet.endpoint = >>>>>> "roles" instead of "ansible/roles". Either way, the endpoint would be >>>>>> v3/content/ansible/roles/ >>>>>> >>>>>> On Fri, Apr 6, 2018 at 10:25 AM, Brian Bouterse <bbout...@redhat.com> >>>>>> wrote: >>>>>> >>>>>>> +1 to option 1. It's consistent. >>>>>>> >>>>>>> On Fri, Apr 6, 2018 at 10:21 AM, Dennis Kliban <dkli...@redhat.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Option 1 is the most consistent. +1 to option 1 >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Apr 6, 2018 at 10:19 AM, Austin Macdonald < >>>>>>>> amacd...@redhat.com> wrote: >>>>>>>> >>>>>>>>> IMO: >>>>>>>>> We should suggest v3/content/<plugin>/<type>/. [Proposal 1] We >>>>>>>>> should mention the other options with the pros, cons in the plugin >>>>>>>>> writer >>>>>>>>> docs. >>>>>>>>> >>>>>>>>> On Thu, Apr 5, 2018 at 10:54 AM, David Davis < >>>>>>>>> davidda...@redhat.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> [0] https://pulp.plan.io/issues/3407 >>>>>>>>>> >>>>>>>>> >>>>>>>>> The correct link is: https://pulp.plan.io/issues/3472 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
