[Pulp-list] REST Musings

[Jay Dobies]

I'm adding the REST APIs for the unit association (read: cloning) stuff. 
What they look like is another discussion since conceptually it's 
crossing boundaries across two resources, but that's not my worry right now.

That call is eventually going to be asynchronous when the coordinator 
layer is finished. Even outside of this call, I'm wondering if making 
things asynchronous is going to complicate the HTTP status code reporting.

I'm of the mindset that the manager layer code is the real brains of 
Pulp. I view the REST API is just an implementation detail on top of it 
and we may eventually support some different interface. So I treat the 
managers are totally standalone, meaning all of my data validation is in 
the managers themselves; the REST layer is an adapter between inbound 
format and the call to the manager.

What I've been doing is using fine grained exceptions coming out of the 
manager to describe, among other things, validation errors. For 
instance, when copying packages from one repo to another, if either repo 
doesn't exist, that's a validation check in the manager call. 
Conceptually I think that makes sense and keeps the manager layer as 
self-contained logic.

That also nicely translates to HTTP status codes. I catch certain 
exceptions differently and translate them accordingly into 404s or 400s.

The problem I think I'm going to run into is that if the entire manager 
call is wrapped into an asynchronous task by the REST controller layer, 
I won't have access to those validation exceptions at the time I need to 
complete the REST call. They'll happen in the task itself, long 
(relatively speaking) after I've returned the HTTP request.

I'm curious if anyone has any ideas on how to handle it. I could split 
out the validation checks in the managers into their own methods. So for 
associate_from_repo, have a call pre_associate_from_repo that will test 
the data and let me know if I shouldn't even bother calling the real 
function. That just feels a bit dirty and annoying.

We could loosen up how RESTful we are and not honor those sorts of HTTP 
status codes as much for asynchronous calls, but I think we're still in 
the mindset of trying to be at least reasonably RESTful.

I suppose we could argue to have the REST controllers do validation on 
their own outside of the managers before calling the functions, but that 
doesn't buy us anything more than the pre_* methods I described above 
and couples the managers to the REST controllers too much for my tastes.

Any thoughts?

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