All,
This is will be a bit long winded but here goes…
I am working on a medical records application that will provide a web
interface (HTML) and REST web services. The application supports many
users and many facilities (clinics, hospitals, etc,). A user can
belong to more than one facility and have a different set of
permissions at each facility.
So far I have modified the restful authentication and restful acl
plugins to deal with a current user and current facility context. In
a web application a simple drop list of facilities that user can
access is enough to change the current facility context of that user.
As I was considering the REST interface to the application, I decided
that it would be to cumbersome for a user to call a resource to change
their current facility (not RESTful?). Instead I am kicking around the
possibility of using nested resources. When a user accesses
http://localhost/facility/2/patients, I change the current facility
context based on the URI. I tested the idea and it works.
I am concerned that it may get too complex with URIs such as /facility/
2/patient/123/vitalstatistics (although it makes perfect sense to
me). I have a number of articles expressing the nesting should not go
beyond 1 level.
-
Would it make more sense to have a URI to change the facility
context or extract it from a normal resource URI e.g. /facility/2/
patient/3? -
In the case of nesting, would it be acceptable to use more than one
level in this scenario? -
When modifying controllers to work in a nested configuration (easy
enough), what is the recommended way of constructing filters to handle
complex relationships. For example: user profiles, facilities and
patients all have a state and country code (multiple foreign key
relationships). My guess is that this could get ugly in very quickly.
Most examples show only simple one-to-many relationships when it comes
to nesting.
If anyone has done something similar before and can offer any insight,
it would be greatly appreciated. Even a pointer to an existing code
base would be enough.
Thanks in advance,
Keith