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.
>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. POSTing and DELETing to either a relationship endpoint or a content endpoint isn't a great fit either. If we had a path " /api/v3/repositories/<repo-id>/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. A simple option could be to allow a POST to a repo version endpoint. If a user did a GET on "/api/v3/repositories/<repo-id>/versions/<num>/", 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 "/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. 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. Thoughts on that? On Wed, Oct 18, 2017 at 12:45 PM, David Davis <[email protected]> wrote: > 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>/content as well but it currently > only lists the contents for a repository. > > 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: > > POST /api/v3/repositorycontents/ (which takes a repo id and content id) > DELETE /api/v3/repositorycontents/<repo-content-id>/ > > We would have to start exposing the repo content id in the api to get this > second link working. > > However, alternatively, we could use a nested route to handle > adding/removing repo contents: > > POST /api/v3/repositories/<repo-id>/content/ (which takes a content id) > DELETE /api/v3/repositories/<repo-id>/content/<content-id>/ > > 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. > > Thoughts? > > [1] https://pulp.plan.io/issues/3073 > [2] https://pulp.plan.io/issues/2873 > > David > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > > -- Michael Hrivnak Principal Software Engineer, RHCE Red Hat
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
