Creation of resources and associations

[Diego Gaviola]

Hi all,

I'm working on a REST API and I had some questions about associations and the way to create resources.

In this case I have 'groups' and 'users', so I have the following URIs:

GET /groups > returns all groups

GET /groups/{id} > returns the indicated group

POST /groups > creates a group

GET /groups/{id}/users > returns users of the group

So far so god. The questions arise when I have to give a URI for the creation of users. Possibilities I think might work are:

POST /groups/{id}/users > creates a user under the group

POST /users > creates a user, but you have to indicate the group they belong to as part of the body

I guess I can provide two URIs, but this will mean that the user have two ways to achieve the same thing, which might not be good.

I would like to know what's your opinion based on your experience. Should I provide both URIs or just one of them? Do you see usability issues with any of these approaches?

Thanks!

[Ian Joyce]

My opinion would be to just have "POST /groups/{id}/users" because you
always have to have the context of the group to create a user. However
there's nothing saying you can have the resource at two different
urls.

--Ian

> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group, send email to
> api-craft+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=en.
>
>

[Diego Gaviola]

Yes, I think that makes sense as a user cannot exist without a group, and a user belongs to only one group. From a usability point of view, looks better to me.

Thanks Ian!

Diego

[Romain Bessuges-Meusy]

Captain Obvious here, but "POST /groups/{id}/users" implies the group - user relation is one-to-many !

If you plan to authorize many-to-many relationship between users and groups, I'd do this, but I'm maybe wrong : 

"POST /users?group=1" or maybe "POST /users?group=1,2"

You could also update the belongings using :

"PUT /users/:userId?group=1,2,3"

What do you think ?

[Jack Repenning]

On Dec 12, 2012, at 1:57 PM, Romain "Captain Obvious" Bessuges-Meusy <romainb...@gmail.com> wrote:

> If you plan to authorize many-to-many relationship between users and groups, I'd do this, but I'm maybe wrong :
> "POST /users?group=1" or maybe "POST /users?group=1,2"

Or, for that matter, if there can be users who are not members of any group.

I'm with Captain Obvious, here.

Jack Repenning

There was no clear line, in my family, between religion and fly fishing.
-- A River Runs Through It, Norman Maclean

[mca]

I advise against using the URI to express this kind of domain-specific detail (e.g. which group[s], if any, to which this user is applied) when changing state of a resource on the server.

Instead, use the *body* to contain this information.

POST /users/

...

<user>

  <groups>...</groups>

</user> 

mca

+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

[Romain Bessuges-Meusy]

After further reflexion I have to agree with you, it's bad to use the "query" string for defining a belonging. 

In your example XML, how do you specify the groups ?

<groups>

     <group id="1/>

</groups>

Or...

<groups>

    <group href="http://api.test.com/groups/1"/>

</groups>

Or...

<groups>

     <group>

          <id>1</id>
          <title>Powerusers</title>
     </group>

</groups>

?

[mca]

<snip>

In your example XML, how do you specify the groups ?

</snip>

There is no one "good" way to handle expressing a list of groups to apply to a user. this is all in the realm of design nad you need to keep your devs, client & server coding, and wire transfer size/speed in mind when desiging your message model.

<groups>1,2,3,4</groups>

<groups>http://example.org/g/1, http://example.org/g/2, ...</groups>

<groups><group href="...">1</group></groups>

and on and on....

mca

+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen