Re: Leaf Resources with child Leaf Resources

On 05:05 pm, [email protected] wrote:
>> From what I understand, once a Resource isLeaf = True, it cannot have 
>>child
>Resources of its own (no requests seem to get routed to them).
>
>This is not really a realistic scenario in a typical REST application 
>where
>nested REST services are common, e.g.

Sorry, perhaps it would be obvious if I looked at the CorePost 
implementation or read its documentation, but I don't understand what 
problem you're having or what question you're asking.

If setting `isLeaf` to `True` isn't appropriate for CorePost's purposes, 
then don't set it to `True`?

Jean-Paul
>Customer REST service:
>
>*GET /services/customer*
>*POST /services/customer*
>*PUT /services/customer/<customerId>*
>*DELETE /services/customer/<customerId>*
>
>Customer Address REST service:
>
>*GET /services/customer/<customerId>/address*
>*POST /services/customer/<customerId>/address*
>*PUT /services/customer/<customerId>/address/<addressId>*
>*DELETE /services/customer/<customerId>/address/<addressId>*
>
>and so on and so forth....
>
>The only way I can support this in CorePost is to separate the concept 
>of a
>Twisted.Web Resource from a standalone REST service for a particular 
>entity.
>
>So let's say I would have a root CorePost Resource hooked up to 
>'services'
>and it would have a child collection of REST service classes and manage
>routing the requests
>to the appropriate one. Each of the REST services for an entity 
>underneath
>that core Resource would NOT be a twisted.web Resource but just a 
>regular
>class.
>
>Does this sound correct?
>Or am I missing some way of using twisted.web Resource objects that 
>would
>allow me to accomplish the same thing without moving away from Resource
>as the ancestor of all my REST service classes?
>
>Thanks
>Jacek