Exposing the RepoContent model via REST API leaves us with the most flexibility in the future. We decided on this design in issue 2873[0].
[0] https://pulp.plan.io/issues/2873 On Wed, Oct 18, 2017 at 1:38 PM, Michael Hrivnak <[email protected]> wrote: > 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 > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
