Currently, we access content units at paths like /api/v3/content/file/. This works great if your plugin has a single content type that corresponds to the name of the plugin.
In pulp_ansible though, we have multiple content types (roles, role versions, etc) so we’ve opened an issue [0] we need feedback on. I’d like to outline the proposals on the issue and get feedback. ## Proposal 1 Use /api/v3/content/<plugin>/<type>/ for all plugins. Examples: /api/v3/content/file/files/ /api/v3/content/ansible/roles/ Advantages: - Consistent across plugins - Can add content types later without problems - Restful. You’re acting on files, roles, etc Disadvantages: - A bit awkward in the case of single content plugins (/file/files) ## Proposal 2 Use /api/v3/content/<plugin>/ for single content plugins and /api/v3/content/<plugin>/<type>/ otherwise. Examples: /api/v3/content/file/ /api/v3/content/ansible/role/ Advantages: - Shorter URLs for single content type plugins - Already what we’re using Disadvantages: - Inconsistent across plugins - Plugin writers can paint themselves into a corner (e.g. I have a single content plugin that implements /api/v3/content/rpm/ and I want to add a new content type like erratum) ## Proposal 3 Use /api/v3/content/<plugin>/ for single content plugins and /api/v3/content/<plugin>-<type>/ otherwise. Basically the same as proposal 2 but with hyphens instead of nesting. Examples: /api/v3/content/file/ /api/v3/content/ansible-role/ [0] https://pulp.plan.io/issues/3407 David
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
