Let's consider an API for some kind of tchat application and that can provide 2 kinds of resources : Room
and User
.
A Room
has 2 properties : users
and admins
. Both contain some instances of User
.A same User
can be stored in both properties, users
and admins
.
A basic get request of a Room
will so provide something like that :
{ id: 1, users: [{ id:1, name:bob}], admins:[{ id:1, name:bob}]}
It seems odd to me to have twice the same data (User
Bob). The client will so have two objects for the same data (which can generate some issues). For instance, if he checks if a User
is listed in the property admins
to define if he is an admin, he might not have the result expected if another instance, based on the same User
, is listed instead.
So in my opinion, I have a few solutions :
- Do not return sub-resources when a
Room
is queried. In that case I will not have duplicates ofUser
while I do not send anyUser
. I then provide access to 2 sub-queries to let the client get the content of the propertiesusers
andadmins
. At this point, it's their responsibility to avoid duplicates.
- Do not return sub-resources when a
- I return the data as presented above (with duplicates). Once again, I let the user handling duplicates.
- I send the
User
once and each other copies are replaced by an alias (probably the id). So the result will be:
{id: 1,users: [{id:1,name:bob}],admins:[1]}
- I send the
That solution works well if I know that all Users
in the property admins
are also listed in the property users
. In a case where some admins
are not actually users
, the property admins
will contain a mix of both : some user-id and some user-instance. The client will so have an extra step of work to handle that property.
- Replace all
Users
by its id and let the client require all thoseUsers
from ids with other requests.
- Replace all
I'm a beginner in Rest api, so I'm sorry if it's a dumb question...