0

Note this question is about when there are multiple relationship types. This is not the same as this question, where there is only a single member relationship.

Say we have persons and organizations. There are two types of relationships between them. One is employment and the other is customer.

I'd like to be able to get the persons associated with an organization based on either employment or customer, as well as the inverse, getting the organizations associated with a person based on either employment or customer.

Usually when I have relationships like this id just go with:

/persons/<person_id>/organization
/organizations/<organization_id>/person

Now, how should I represent this when the type of relationship is ambiguous, in my example it could be either employment or customer. Here are some alternatives I've come up with for accessing all persons who are customers of an organization:

/customers/organizations/<organization_id>/persons
/organizations/<organization_id>/customers/persons
/organizations/<organization_id>/persons?only_customers=true
/organizations/<organization_id>/persons?relationship=customer

Under the hood these would be modeled as four DB tables:

person <- customer -> organization
person <- employment -> organization

Are there any other ways of doing this? Which would be the canonical way? I'm not very keen on creating new object types. It might be obvious that person could be replaced with employee, or something like that, but that would have huge implications for other parts of the API design and client implementation, thus is not on the table.

  • Return a generic entity, perhaps a "contact." – Robert Harvey May 29 at 14:49
0

Reminder: REST doesn't care what spellings you use for your URI.

As far as REST is concerned, it is perfectly reasonable for ACME Inc to be identified by /a05b7d44-8319-4609-bb17-6234b0a61e54, and for ACME Inc Employees to be identified by /2ae6f0a9-e8ea-4b0d-899e-39a11cd92fe1 and for ACME Inc Customers to be identified by /fcb01a22-8dd6-45d6-a489-da143fca834e.

At the server, you might prefer to instead use a hierarchical spelling, because doing so would allow you to take advantage of relative resolution. So you might instead have /a05b7d44-8319-4609-bb17-6234b0a61e54, /a05b7d44-8319-4609-bb17-6234b0a61e54/2ae6f0a9-e8ea-4b0d-899e-39a11cd92fe1, /a05b7d44-8319-4609-bb17-6234b0a61e54/fcb01a22-8dd6-45d6-a489-da143fca834e, allowing you to use dot-segments to move up the identifier hierarchy.

You would normally rely on links to communicate the relation between two URI.

What this does is allows the server to encode into the URI any information it needs to resolve the correct resource later. That allows us to use spellings like

/organization/7/employees
/employees/organization/7
/employees?organization=7
/organization/7?employees
/orgnization/7/people?employees
...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.