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

[Pulp-list] REST Musings

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

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