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