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 <[email protected]> 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 <[email protected]> > wrote: > >> >> >> On Tue, Apr 10, 2018 at 8:20 AM, David Davis <[email protected]> >> 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 <[email protected]> >>> wrote: >>> >>>> On Mon, Apr 9, 2018 at 1:32 PM, Austin Macdonald <[email protected]> >>>> 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 <[email protected]> >>>>> wrote: >>>>> >>>>>> +1 to option 1. It's consistent. >>>>>> >>>>>> On Fri, Apr 6, 2018 at 10:21 AM, Dennis Kliban <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Option 1 is the most consistent. +1 to option 1 >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 6, 2018 at 10:19 AM, Austin Macdonald < >>>>>>> [email protected]> 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 <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> [0] https://pulp.plan.io/issues/3407 >>>>>>>>> >>>>>>>> >>>>>>>> The correct link is: https://pulp.plan.io/issues/3472 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pulp-dev mailing list >>>>>>>> [email protected] >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> [email protected] >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >> >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
