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 _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
