Re: Leaf Resources with child Leaf Resources
| Newsgroups | gmane.comp.python.twisted.web |
|---|---|
| Message-ID | <20120229203203.4576.1292601871.divmod.xquotient.73@localhost6.localdomain6> |
On 07:53 pm, [email protected] wrote: >See comments below > >On Wed, Feb 29, 2012 at 2:45 PM, <[email protected]> wrote: >>On 06:09 pm, [email protected] wrote: >> >>Well.... my first reaction is that this doesn't make sense. Leaves >>don't have leaves. That's what makes them leaves. >> >>Your CustomerRestService is not a leaf resource. >it handles GET/POST/PUT/DELETE requests for the Customer entity. If I >am >coding in raw twisted.web, that means >I would need to handle the render_GET, render_POST, etc. in this class. > >Isn't that what classifies it as a leaf resource (i.e. one that >actually >handles HTTP requests instead of just passing them down to a child)? If CustomerRestService is the resource for requests like: GET /services POST /services PUT /services DELETE /services That does not make it a leaf resource. That just makes it a resource. If CustomerRestService is the resource for requests like: GET/POST/PUT/DELETE /services GET/POST/PUT/DELETE /services/something/else That makes it a leaf resource. > >> >about nested URL schemes, e.g. >> >>Right. Because "nested leaf resource" is self contradictory. > >Well, not in REST...nested resources under another other is the norm in >defining URL schemes in REST apps. I don't think REST has anything to say about "leaf resources", because they're an API convenience invented by Twisted Web. Jean-Paul > >Or does the concept of a REST service for an entity simply not map at >all >to what Twisted Web defines as a Resource? > >Apart from what I said above, and still not really understanding why >you >>want this, the implementation of the traversal mechanism is exposed as >>`twisted.web.resource.getChildForRequest`. After you stop traversal >>with your first "leaf" resource, you can finish it by calling >>`getChildForRequest` manually, and then manually rendering the >>resulting >>resource. >Let me look at that. But it seems counter-intuitive for a typical REST >app >structure.... > >Jacek