[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] REST Musings



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]