[Pulp-list] REST Musings

[Jay Dobies]

> 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.

The nice part is that in the task itself all of the fine grained error 
reporting is still accessible. So we're not losing information, just 
kinda shuffling around where it is by tweaking the interpretation of 
what it is the API call itself actually means (i.e. "success" means 
queued, not necessarily a successful execution).


-- 
Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org