[Pulp-dev] Many-to-many joins in the API

[Michael Hrivnak]

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 <daviddavis at redhat.com> 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
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>


-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171018/c25ddf86/attachment.htm>