<div dir="ltr"><div>I spoke with daviddavis about this and I would like to narrow the scope a bit. This discussion should be limited to endpoints that deploy tasks. The possibility for collisions that David pointed out regarding v3/content/<type>/ is real, but should be discussed separately because Content objects should follow the pattern of the other plugin defined objects. All of them are master/detail so the namespacing v3/plugin/<type>/content/ would go deeply against the grain.</div><div><br></div><div><br></div><div>On Mar 15, 2018 10:53, "David Davis" <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_3113578106519178207m_8399948641677187783m_5283774274098375439m_-8510984043741993720quote gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></blockquote><blockquote class="m_3113578106519178207m_8399948641677187783m_5283774274098375439m_-8510984043741993720quote gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>For task routes, plugins could still route to a pulpcore viewset/action:</div><div><br></div><div>User route: POST /api/v3/plugin/<font color="#000000">file</font>/repository<wbr>_version/ add_content=[…]</div><div><br></div><div>Routes to: POST /api/v3/tasks plugin=file task=create_repository_version add_content=[…]</div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><font color="#3d85c6"></font></div></div></div></blockquote><div><br></div><div>AFAIK, we don't have a good mechanism for validating and re-routing endpoints quite like this. Instead, a view or viewset would be created, validation performed, and then a task is deployed. The task itself could be a vanilla task from pulpcore though. Another issue is that a POST to v3/plugin/file/repository_version/ implies that the resultant repository_version is typed in some way. The created resource href would still take the form v3/repositories/1234/versions/2/, so I think this is a little misleading. </div><div><br></div><div>For the other endpoint:</div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> /api/v3/tasks plugin=file task=create_repository_version add_content=[…]</span></div><div><br></div><div>There is a still the problem is that POST requests should not contain parameters that influence the allowable parameter set. For instance, plugin=python might require an additional parameter that is not allowed for the file plugin. In particular, this affects the auto-documented REST API.</div><div><br></div><div>However, the concept in general could work. I've adapted David's suggestion and will present it side by side with the original idea. Note, this only applies to "actions", which are sync, publish, add/remove, and plugin-specific actions (including rich-dependency adding). </div><div><br></div><div>The difference between the two ideas is based in semantics. Both would deploy the same task functions.<br class="gmail-Apple-interchange-newline"></div><div><br></div><div>"Action Based"</div><div>POST v3/plugin/file/sync/ </div><div>Note that "sync" is singular. This is a file-plugin action to sync using the body parameters.</div><div><br></div><div>"Task Object Based"</div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">POST v3/tasks/file/syncs/ </div>Note that "syncs" is plural. This is a POST that creates a file-sync task object,.<br class="gmail-Apple-interchange-newline"><br></div><div>Discussion:</div><div>Another consideration is "Where will a Live API live?". A benefit of David's proposal is that we would be providing plugins with a namespaced area to do whatever they need, from live api to actions. We probably would want to create this namespace for things like live apis even if we go in the tasks/file/syncs/ direction. The only downside of this part of David's proposal is that our endpoints will still be "action" verbs instead of nouns, and I am ok with that.</div></div></div></div>
</div>