Application Architecture - Nested Resources


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.

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

2. In the case of nesting, would it be acceptable to use more than one
level in this scenario?

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


I wonder if you're not missing a model here, something that represents
the patient-at-a-facility combination. I'm not sure what it would be
called, let's just call it a "registration" for now, something that
scope's a patient's data to a particular facility.

Then you'd have URLs like:


You'd still have /facilities and /patients for the "master" lists of
each, but a specific patient-facility combination would be represented
by a registration record (i.e., on the model side, facility
has_many :patients :through => :registrations). A Registrations
controller could then be a simple RESTful interface on top of that.

Does that help?



Sort of... the reason I want to nest 'encounters' under facilities (I
would have a facility has_many :encounters :through => :registrations,
I am still at the conceptual stage) is so I can extract the facility
id and set the current facility context for security purposes, much
like the concept of a current user. I didn't want to make the user
call a separate URI in order to do this. Are you suggesting that I
could get the "encounter" first and then use the model association to
get the facility? If so didn't think of that :slight_smile: although that would
mess with the way restful_acl works.

Thanks for taking the time to answer as I worded my question in a not
so succinct manner!