[Pulp-dev] Content paths in Pulp 3
David Davis
daviddavis at redhat.com
Thu Apr 5 14:54:39 UTC 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180405/a76e774b/attachment.htm>
More information about the Pulp-dev
mailing list