> I can't speak for the OP, but our API is built using traversal (I > thought about using a hybrid approach but decided not to do that) - I > think there are a number of general misconceptions many programmers have > about how to build a "RESTful" API; that's a conversation *not* for this > thread though! > > I think traversal can fit in well with a (IMO of course) well designed > REST api. >
I agree, and actually we are indeed actually using traversal for our restful api admin interface too. We did this by making some proxy container objects, we call ResourceContainers, that represent a class of resources. The resource classes are registered as utilities in the zca registry, allowing one to register a class of object to a key name. So given the url: /admin/foobar/1/edit, we have the following: - the resource root for the admin app looks for the utiltiy providing the IResourceClass interfacere, named 'foobar'. If it finds one, it instantiates a ResourceContainer for the persistent Foobar class. ( so the utility is actually a *class* not an object, ie utility lookup returns the class Foobar, as opposed to adapter lookup which instantiates and object) - the ResourceContainer object looks in the db for an item of it's resource class with the id 1 - traversal ends with that item being found, and that item provides IFoobar, which inherits from IResourceItem - the edit view gets looked up for items providing IFoobar, if none are found specific for IFoobar, the edit view for IResourceItem will be found That all works really well for us for restful APIs and is a nice way to hook security in there because the ResourceContainer proxies can do whatever kind of class level security check you want, building ACLs as you go, and then you can override them for row-level security when you look up the individual item. We're using the ZCA directly a lot for this, decorating objects with whatever interfaces they need to provide, and building/modfiying ACLs as we go down the traversal chain. I like this approach because then at the end of traversal, access control is always ultimately handled by view look up and ACLs, but we can provide those ACLs in a few different places. However, for the client side of the app, we've found that looking up pages with a restful api ( ie /public/page/1/view ) is way less intuitive for our users than using a traversal based one ( /content/about_us/the_founders etc ). So we're actually giving our clients two ways to edit content, they can use the admin app side, or go to an item and click edit. In either case, an edit view still gets found for the correct item, the difference is only in how they get there. This seems to make them happy! =) FWIW, given the amount of utility and adapter look up we're doing, we've found using ZCML to be preferable. YMMV. hope that's useful to someone! iain -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
