<div dir="ltr">Thank you! Good idea to have an additional one.<div>I'm on the fence between ReadOnly and just Generic one without any mixins.</div><div><br></div><div>Any other opinions/suggestions?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2019 at 4:35 PM Matthias Dellweg <<a href="mailto:dellweg@atix.de">dellweg@atix.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would do a variation of 1. :<br>
Provide a ReadonlyContentViewSet with only GET mixed in and leave the<br>
'standard' ContentViewset as is.<br>
Cheers, Matthias<br>
<br>
On Wed, 2 Oct 2019 16:16:14 +0200<br>
Tatiana Tereshchenko <<a href="mailto:ttereshc@redhat.com" target="_blank">ttereshc@redhat.com</a>> wrote:<br>
<br>
> Current implementation of ContentViewset<br>
> <<a href="https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/content.py#L98-L102" rel="noreferrer" target="_blank">https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/content.py#L98-L102</a>><br>
> includes<br>
> mixins for create (POST) and retrieve/list (GET).<br>
> In case a plugin doesn't need to support POST for a content endpoint,<br>
> a plugin writer compiles a viewset from the mixins they need, e.g.<br>
> distribution trees and custom metadata<br>
> <<a href="https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/app/viewsets.py#L233-L258" rel="noreferrer" target="_blank">https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/app/viewsets.py#L233-L258</a>><br>
> (same<br>
> use case is expected for modularity endpoints)<br>
> This leads to the inconsistent REST API.<br>
> <br>
> # ContentViewset is used<br>
> /pulp/api/v3/content/rpm/advisories/<br>
> <br>
> # custom plugin content viewset<br>
> /pulp/api/v3/distribution_trees/rpm/distribution_trees/<br>
> <br>
> Possible solutions:<br>
> 1. Make ContentViewset more generic (no mixins, or only GET ones?)<br>
> and let plugins include any mixins they need.<br>
> This option might be painful to switch to for plugin writers, because<br>
> every plugin will be affected and will need to make this change.<br>
> At the same time probably not many plugins support upload for every<br>
> content type, so in many cases the POST is broken/not used anyway.<br>
> <br>
> 2. Disable POST at the plugin level in some other way.<br>
> I'm not sure if there is any native option to disable it.<br>
> Hacky way is to override `create` method which will return<br>
> appropriate HTTP error that POST is not supported.<br>
> <br>
> 3. Make plugin writers manually define a proper endpoint name.<br>
> Apart from not being reliable, I'm not sure how to do it because of<br>
> how we tweak endpoint generation.<br>
> Notice the distribution trees example ^, "distribution_trees" is used<br>
> twice in the endpoint.<br>
> <br>
> 4. Any other solutions? Easy ones which I missed?<br>
> <br>
> Thank you,<br>
> Tanya<br>
</blockquote></div>