<div dir="ltr">Thanks for the classifications.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 2, 2018 at 2:37 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span> wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div dir="ltr"><div><div>I think of these actions as 2 new types of resource in Pulp. Unlike Remotes(Importers currently) and Content, these resources are singletons that each plugin provides. Since users don't need to create new instances of these resources it makes sense that they are represented by a View instead of a ViewSet. Though we don't even need to explain that to plugin writers. We just need to tell them that all operations that their plugin provides for users need to be sublassed from ActionView. <br></div></div></div></span><div><br></div><div>From the users point of view a GET on /api/v3/versionsactions/ to find a versionaction href is the same as performing a GET on /api/v3/remotes/ to find the href for a specific remote to sync from. <br></div><div><br></div><div>Auto documentation would work perfectly.<br><br></div></div></div></div></blockquote><div><br></div><div>Its not that it would be "broken" or "wrong". I just think that users expect the documentation to include behavior and parameters-- ideally, there should be enough information to create a request. In this case however, the documentation just explains how to retrieve the necessary information. It works, but I don't think it is ideal that the user needs to make other GET requests to learn how to use an API endpoint.<br></div></div></div></div>