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

Jeff Ortel jortel at redhat.com
Wed Oct 18 20:41:52 UTC 2017

On 10/18/2017 11:45 AM, David Davis 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/
> DELETE /api/v3/repositories/<repo-id>/content/<content-id>/

This ^^ seems more appropriate and intuitive for the REST API.  Join tables are an implementation detail.

> 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 <https://pulp.plan.io/issues/2873>
> David
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171018/db70796b/attachment.sig>

More information about the Pulp-dev mailing list