[Twisted-web] Leaf Resources with child Leaf Resources

exarkun at twistedmatrix.com exarkun at twistedmatrix.com
Wed Feb 29 15:32:03 EST 2012


On 07:53 pm, jacek99 at gmail.com wrote:
>See comments below
>
>On Wed, Feb 29, 2012 at 2:45 PM, <exarkun at twistedmatrix.com> wrote:
>>On 06:09 pm, jacek99 at gmail.com 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



More information about the Twisted-web mailing list