[Pulp-dev] [pulp 3] proposed change to publishing REST api

[Michael Hrivnak]

On Mon, Oct 23, 2017 at 11:06 AM, Jeff Ortel <jortel at redhat.com> wrote:

>
> On 10/23/2017 09:55 AM, Michael Hrivnak wrote:
> >
> > A task status should not include an exhaustive list of every resource
> created. For example, a publish task
> > should not include a reference to every metadata artifact it made. It
> would be sufficient to include a
> > reference to the publication, the task's primary output, which then can
> be used to reference subordinate
> > resources.
> >
> > On a task status representation, this could be included in a field
> called "created_resources", "output",
> > "return_value", or similar.
>
> Tasks (status) are a transient mechanism used to accomplish work and
> should not be used to track resources
> created.  Once the task has completed, the user should be free to forget
> the task ID and be able to use
> natural keys to find and inspect resources that got created/updated.
>

I'm also not sure what natural key a publication will be able to reliably
have. If I publish the same repo three times, how do I know which
publication resulted from each task? Or when a repo version is created by a
sync, how would an end user know which version was created by the task they
were monitoring?

Just as a 201 response should include a link to the resource that was
created, a 202 should include a link to a resource that can monitor the
status of the request to create something. Why would that status monitor
not upon completion include a link to the resource that got created? It's
fulfilling the same end goal that could otherwise be achieved from a 201
response, but with an asynchronous part of the workflow.

-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171023/a67e4fe4/attachment.htm>