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.
On Mar 15, 2018 10:53, "David Davis" <davidda...@redhat.com> wrote: 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. For task routes, plugins could still route to a pulpcore viewset/action: User route: POST /api/v3/plugin/file/repository_version/ add_content=[…] Routes to: POST /api/v3/tasks plugin=file task=create_repository_version add_content=[…] 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. For the other endpoint: /api/v3/tasks plugin=file task=create_repository_version add_content=[…] 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. 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). The difference between the two ideas is based in semantics. Both would deploy the same task functions. "Action Based" POST v3/plugin/file/sync/ Note that "sync" is singular. This is a file-plugin action to sync using the body parameters. "Task Object Based" POST v3/tasks/file/syncs/ Note that "syncs" is plural. This is a POST that creates a file-sync task object,. Discussion: 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.
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev