[Pulp-list] REST Musings

[Jason L Connor]

On Thu, 2012-01-05 at 10:14 -0500, Jay Dobies wrote:
> 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.

+1 this is exactly how I've always seen the rest controllers

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

Originally I had envisioned the web services as doing the validation and
leaving the (at the time) api to just do the work. I've found this
really muddles the web services layer and have recently been putting
validation into it's own package.

This makes it reusable by other api layers and allows the rest api to
quickly do validation before invoking more cumbersome library calls.

However this approach also complicates the code. Having to always call
into the validation package before calling into pulp's internal api is
cumbersome in it's own right. And implementing a validation layer
separate from the internal api make implementing and maintaining that
layer difficult.


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

-- 
Jason L Connor
linear on freenode #pulp
http://pulpproject.org/
RHCE: 805010912355231
GPG Fingerprint: 2048R/CC4ED7C1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20120105/6d73e3a9/attachment.sig>