>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