<div dir="ltr"><div>+1 to what Justin said. I think it's a huge benefit to have the differences between plugins show up in the api docs together.</div><div><br></div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>
<p style="font-weight:bold;margin:0;padding:0;font-size:14px;text-transform:uppercase;margin-bottom:0"><span>Dana</span> <span>Walker</span></p>
<p style="font-weight:normal;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>Associate Software Engineer</span><span style="font-weight:normal;color:#aaa;margin:0"></span></p>
<p style="font-weight:normal;margin:0;font-size:10px;color:#999"><a style="color:#0088ce;font-size:10px;margin:0;text-decoration:none;font-family:'overpass',sans-serif" href="https://www.redhat.com" target="_blank">Red Hat <span><br><br></span></a></p>
<table border="0"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"> <img src="https://www.redhat.com/files/brand/email/sig-redhat.png" width="90" height="auto"></a> </td>
</tr></tbody></table>
</div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 1, 2019 at 2:00 PM Justin Sherrill <<a href="mailto:jsherril@redhat.com">jsherril@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To me this makes a lot of sense, allows for plugin flexibility, and is <br>
more consistent across plugins.<br>
<br>
I feel like this will make differences between plugins more <br>
understandable by reading the api docs, rather than scanning the <br>
README's of the respective plugin and trying to work out what is different.<br>
<br>
Justin<br>
<br>
On 2/28/19 1:42 PM, Austin Macdonald wrote:<br>
> Now that we have a handful of plugins that have somewhat different <br>
> workflows, surprising user-facing differences in the interface for <br>
> plugin-related actions are becoming apparent.<br>
><br>
> Example: Publish<br>
> File:<br>
> Create a publisher<br>
> v3/publishers/file/1/publish/ repository=$REPO<br>
> Ansible:<br>
> (no publisher)<br>
> v3/publications/ repository=$REPO<br>
><br>
> The difference is not huge, having a different endpoint does defy <br>
> expectations of a user who is familiar with one plugin, who then moves <br>
> to another plugin.<br>
><br>
> Plugins can also implement other endpoints, like RPM's one-shot <br>
> upload. The problem is that we have mixed idioms. Plugins are <br>
> encouraged to create task endpoints for objects (remote's sync, <br>
> publisher's publish), but they are also encouraged to create arbitrary <br>
> endpoints for any other actions. Users are not able to form reasonable <br>
> expectations for this part of the interface from plugin to plugin.<br>
><br>
> Proposal:<br>
> We could move all "actions" into a single area, namespaced by plugin <br>
> (by convention). This would allow the plugins the freedom to do <br>
> whatever they need to do while keeping the interface consistent and <br>
> predictable for users of multiple plugins. These "actions" could be <br>
> synchronous or asynchronous. Importantly, this would also create a <br>
> logical "group" of endpoints a user could look for in the REST API docs.<br>
><br>
> Examples:<br>
> v3/actions/file/publish/ publisher=$PUB repository=$REPO<br>
> v3/actions/ansible/publish/ repository=$REPO<br>
> v3/actions/rpm/upload/ file@./foo-4.1-1.noarch.rpm repository=$REPO<br>
><br>
> Will this push back the RC?<br>
> No. The changes to the plugin API will be small, and the changes to <br>
> each plugin would be moving sync and publish endpoints, leaving the <br>
> logic almost identical. I anticipate the most time consuming aspect of <br>
> this will be adjusting the documentation of each plugin-- but since <br>
> they will follow similar patterns, this shouldn't be too much work either.<br>
><br>
> To sum up:<br>
> We should move sync and publish endpoints to <br>
> /actions/<plugin>/<action_name>/ to be consistent with other <br>
> plugin-defined actions like one-shot upload. This will look very nice <br>
> in swagger docs, and should provide more consistent workflows for <br>
> users of multiple plugins.<br>
<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>