I'm concerned that having a single endpoint with a complicated combination of parameters that control how the endpoint behaves isn't ideal.  Especially since some of the parameters are mutually exclusive.  Seems that having /api/v3/repositories/<id>/versions/ endpoint do one thing is cleaner.  Should we go with the approach of simpler endpoints, I would suggest something like /api/v3/repositories/<id>/versions/clone/ that accepts parameter "version" in the body that is an href to an existing version.  If we go with a single complex endpoint, I'd suggest "cone_version" as the parameter.

As an aside, the existing add_content_units and remove_content_units should be renamed.  "_content" is already plural so adding the "_units" is the singular form that's made plural.  Should just be add_content, remote_content.

On 02/16/2018 03:30 PM, Dennis Kliban wrote:
Earlier today several of us discussed issue 3360[0]. In our discussion we concluded that it is valuable for users to be able to create exact copies of repository versions within a repository and across different repositories. I have updated the issue to reflect what we discussed. We decided that this use case should be included in the MVP.

The issue currently states that the parameter will be called 'mirror_repository_version'. However, we could not agree if that is actually the best name for this parameter. Suggestions for a better name are welcome on this thread or as comments on the issue.


[0] https://pulp.plan.io/issues/3360

-Dennis


_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Reply via email to