<div dir="ltr">I have an amendment to this proposal. Instead of namespacing just the plugin task routes, I’d propose we namespace all plugin routes. Thus all plugin routes would be namespaced under something like “/api/v3/plugin/<plugin name>/“. For example, “/api/v3/content/file/” gets moved to “/api/v3/plugin/file/content/” and so on.<div><br></div><div>For task routes, plugins could still route to a single pulpcore viewset/action:</div><div><br></div><div>User route: POST /api/v3/plugin/file/repository<wbr>_version/ add_content=[…]</div><div>Routes to: POST /api/v3/tasks plugin=file task=create_repository_version add_content=[…]<br></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">User route: POST /api/v3/plugin/file/syncs/ repo=repo_href importer=importer_href</span></div><div><span style="font-size:12.800000190734863px">Routes to: POST </span>/api/v3/tasks plugin=file task=sync <span style="font-size:12.800000190734863px"> </span><span style="font-size:12.800000190734863px">repo=repo_href importer=importer_href</span><br></div><div><br></div><div>We’d give a way for plugins to specify which URLs map to a task and what the expected parameters are.</div><div><br></div><div>Benefits:</div><div>- Avoids all potential conflicts as long as plugin names are unique. For example, if my plugin has multiple content types and one is ‘file’, I can set up “/api/v3/content/file” which will conflict with pulp_file.<br></div><div><div><div>- No leaky abstraction in our URLs. Users don’t have to know whether a particular URL produces a task or not to find its URL.</div></div><div>- It’s easy to find all the plugin routes (not just tasks routes) for a particular plugin. They’re at “/api/v3/plugin/<plugin name>/“.<br></div><div>- Plugins have more freedom and aren’t constrained to defining certain predefined routes.</div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 14, 2018 at 3:58 PM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I reviewed this proposal with Austin, mainly from the perspective of an end user. In my opinion, this proposal is a good one. I find the semantics intuitive and I think they do a good job of adhering to the <a href="https://www.martinfowler.com/articles/richardsonMaturityModel.html" target="_blank">Richardson Maturity Model</a>. And although I don't have a great knowledge of how plugins work, I think this will grant more flexibility to plugins.<br></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>