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
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
