<div dir="ltr">Whenever we get to versioning repositories, that will have a big impact on the issues you're raising. Regardless of how exactly a user causes content to be added or removed from a repo, the main result of the operation will be the creation of a new repo version. For example, a sync task would create a new version as its output, and that version would reference the creation and removal of relationships to content.<div><br></div><div>From a REST standpoint, that changes what expectations we need to meet. For one, the RepositoryContent model will change, and we probably won't want to allow users to directly create/update/delete those entries, on the principle that a repo version is immutable. If the user wants to add or remove content from a repo, the output must always be a new version.</div><div><br></div><div>POSTing and DELETing to either a relationship endpoint or a content endpoint isn't a great fit either. If we had a path "<span style="font-size:12.8px">/api/v3/repositories/<repo-id></span><wbr style="font-size:12.8px"><span style="font-size:12.8px">/content/", it would only be a shortcut to the set of content in the repo's current version. A user should not expect to be able to change a content set directly, so giving them write access there could be misleading.</span></div><div><br></div><div>A simple option could be to allow a POST to a repo version endpoint. If a user did a GET on "<span style="font-size:12.8px">/api/v3/repositories/<repo-id>/versions/<num></span><span style="font-size:12.8px">/", they should probably get a representation that includes what content was added and removed by that version. We could allow them to POST a similar representation to </span> "<span style="font-size:12.8px">/api/v3/repositories/<repo-id>/versions/", which would create a new version that makes the desired additions and removals. From a REST standpoint, I think that's the most natural way to facilitate arbitrary adding and removing of content given a model that includes repo versions.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">That approach could also solve our upload problem, where we don't want 100 uploads to create 100 repo versions. A user could create 100 new content units via upload, and then associate them to a repo in one operation.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thoughts on that?</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 18, 2017 at 12:45 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Working on issue #3073 [1], there was a discussion that came up about how to best handle updating many-to-many joins in the API. We currently have a many-to-many relationship between repositories and contents which is handled by a RepositoryContent model. The api for this model is at /api/v3/repositorycontents/ (more info here [2]). But we also have an API already at /api/v3/repository/<repo-id>/<wbr>content as well but it currently only lists the contents for a repository.<div><br></div><div>I think there are two options for supporting many-to-many joins in the API. First, we could continue to expose the join model and have routes like:</div><div><br></div><div>POST /api/v3/repositorycontents/ (which takes a repo id and content id)</div><div>DELETE /api/v3/repositorycontents/<<wbr>repo-content-id>/</div><div><br></div><div>We would have to start exposing the repo content id in the api to get this second link working.</div><div><br></div><div>However, alternatively, we could use a nested route to handle adding/removing repo contents:</div><div><br></div><div>POST /api/v3/repositories/<repo-id><wbr>/content/ (which takes a content id)</div><div>DELETE /api/v3/repositories/<repo-id><wbr>/content/<content-id>/</div><div><br></div><div>This second scheme would essentially hide the RepositoryContent model from API users. I am not sure if that’s a good thing or a bad thing.</div><div><br></div><div>Thoughts?<br><div><div><br></div><div>[1] <a href="https://pulp.plan.io/issues/3073" target="_blank">https://pulp.plan.io/<wbr>issues/3073</a><br clear="all"><div><div class="m_-7047160002590884058gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>[2] <a href="https://pulp.plan.io/issues/2873" style="font-size:12.800000190734863px" target="_blank">https://pulp.plan.io/<wbr>issues/2873</a></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>David<br></div></font></span></div></div></div></div></div></div></div>
</div></div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div>