Application Architecture - Nested Resources


#1

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.

  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/
    patient/3?

  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,

Keith


#2

On Jan 20, 7:39 am, KRD removed_email_address@domain.invalid wrote:

So far I have modified the restful authentication and restful acl
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.

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:

/registrations/123/vitals

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?

Jeff
purpleworkshops.com
switchingtorails.com


#3

Thanks,

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!

Keith