[Pulp-list] REST Musings

[James Slagle]

On Thu, Jan 05, 2012 at 01:12:32PM -0500, Jay Dobies wrote:
> >My 2¢: I'm leaning towards keeping how we manage async tasks today.
> >Which is not worry too much about the http status code part of rest.
> >They get a 202 accepted on kick off and the status url either returns
> >200 ok if it has a status to report or a 404 not found if the server has
> >no knowledge of the task or job id and that's it.
> >
> >I believe this matches you first suggestion of loosening up how restful
> >we are. The http status codes are grossly restrictive as it is. No need
> >to keep trying to force a round peg into a square hole here (so to
> >speak).
> 
> I like this and I think it's justified. For async calls, it isn't so
> much the execution of the call itself that we're returning the
> status of, it's the creation and queueing of the task itself. So
> looked at in that light, 202 v. some error related to attempting to
> create the task doesn't feel so dirty. It's just a matter of
> explaining that contract to the API caller.

I agree.  If the result of the API call is to kick off an asynchronous task,
the HTTP status codes should apply to the task or job resource that is
returned.  If you're expecting a task to get created, getting a 404 back b/c a
repo is not found, wouldn't really make sense I don't think.

As you already mentioned, I think we need to clearly document which API's
are asynchronous in nature and those API's would have standard return codes
that relate to the task resource that is returned.

--
-- James Slagle
--