0

I have a collections of customers and each customer has a relationships resource that looks like this:

{ "customerId" : "string", "accounts" : [{ "accountId" : "string", ... }], "profiles" : [{ "profileId" : "string", ... }] }

I am building a REST api to provide access to this resource and sub resources like accounts and profiles.

This is the URIs that I came up with:

  1. /customers/{id}/relationships - To return the above resource
  2. /customers/{id}/relationships/accounts - To return accounts sub resource
  3. /customers/{id}/relationships/profiles - To return profiles sub resource

But one issue I see is that relationships resource looks like a collection. So it will be expected to have a {relationshipId} after that. But actually it is a single resource. How can I design URIs for this?

Improve this question
2
  • For clarity, relationships is a single object containing multiple types of relationship? If so why does relationships exist? couldn't you do /customers/{id}/accounts and /customers/{id}/profiles and get around the issue entirely? Commented Aug 22, 2019 at 15:58
  • Mainly because /customers/{id} resource is not available for us to make changes. Also there are requirements where we need to return both accounts and profiles relationships together. Thats why we have a parent /relationships resource Commented Aug 26, 2019 at 20:51

2 Answers 2

Reset to default
1

If 'relationships' is a single object and not a collection you could go several ways.

  1. Remove it entirely so you have /customers/{id}/accounts and /customers/{id}/profiles
  2. Rename it to something else /customers/{id}/related/accounts
  3. Leave it as is... This still works as 'accounts' and 'profiles' become id's beneath the relationships collection (/customers/{id}/relationships/{id(accounts|profiles)}

It is always good to follow standards. But often you can spend too long worrying about minor issues in which ultimately no matter which way you go, will not make a massive difference.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

The /customer/{id} resource is not available to us to modify. Also we have requirement where we need to return both accounts and profile relationships together. So a parent resource is necessary.
If you could modify the /customer/{id} resource you could satisfy your requirement by simply returning both accounts and profile relationships in your customer object. Unfortunately, if you can't modify it this doesn't help you. But neither of these problems prevent you from going with option 2 or 3?
Thanks @Leigh for the comments. Finally we decided to go with 2nd option.
0

You need to decide if relationships is a document or a collection. See this for definitions:

https://restfulapi.net/resource-naming/

If you think it is a collection then /customers/{id}/relationships/accounts is correct where accounts is an id of the resource in collection.

If you think of it as a document then you are requesting a limited view of the document and you can use something like /customers/{id}/relationships?$select=accounts if you wish to follow it the OData way

https://learn.microsoft.com/en-us/aspnet/web-api/overview/odata-support-in-aspnet-web-api/using-select-expand-and-value#using-select

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.