No subject

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

--bcaec554db9e79c1e104ba1d5bd8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable