I'd suggest something similar to what Bryan came up with
PUT api/v2/operatingsystems/24/add_architecture/2
PUT api/v2/operatingsystems/24/remove_architecture/2
The reason would be that the relation is not a resource but rather an
attribute. I'd use PUT as the operation is idempotent and from users
perspective it alters the os resource.
Makes sense?
M
···
On 01/30/2014 02:31 PM, Bryan Kearney wrote:
> On 01/30/2014 08:19 AM, Joseph Magen wrote:
>> ----- Original Message -----
>>> From: "Bryan Kearney"
>>> To: foreman-dev@googlegroups.com
>>> Sent: Thursday, January 30, 2014 3:13:37 PM
>>> Subject: Re: [foreman-dev] Updating many-to-many relationships
>>>
>>> On 01/30/2014 02:42 AM, Joseph Magen wrote:
>>>> To be specific and atomic, then you need to treat the many-to-many
>>>> relation
>>>> as its own resource. This is not the case with our example
>>>>
>>>> PUT api/v2/operatingsystems/24
>>>>
>>>> which update all the attributes AND associations for resource
>>>> operating
>>>> system #24
>>>>
>>>> The RESTful way to only add or delete an association (similar to
>>>> what we
>>>> did for host_classes and hostgroup_classes) is this below: (Note
>>>> that BOTH
>>>> the architecture id and operating system id's already exist)
>>>>
>>>> Create a new association
>>>> POST api/v2/operatingsystems/24/architectures_operatingsystems -d
>>>> {'id': 1}
>>>>
>>>> object created
>>>> {
>>>> 'id': 555
>>>> 'operatingsystem_id': 24
>>>> 'architecture_id': 1
>>>> }
>>>>
>>>> Delete an association
>>>> DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555
>>>>
>>>> This is similar to what Bryan may thought of when he wrote
>>>>
>>>>> What about a
>>>>> PUT api/v2/operatingsystems/24/architectures
>>>>
>>>> But the issue here is that PUT requires an ID of a resource to update.
>>>
>>>
>>> yeah... I should have put POST.
>>>
>>>>
>>>> The 'problem' with the atomic restful way is that most 'simple'
>>>> API's don't
>>>> expose the database internals such as id #555 on a join table which is
>>>> meaningless to the user.
>>>
>>> I would make it architectures. That way the join parrt is hidden a bit.
>>
>>
>> POST api/v2/operatingsystems/24/architectures -d {'id': 1}
>>
>> This would be confusing, since in RESTful style, a POST on a
>> collection (architectures) creates a new architecture.
>
>
> You are correct.. but this for me is when the REST WILL SOLVE ALL
> ISSUES argument starts to fail. Haveing a resource which is
>
> api/v2/operatingsystems_architectures_relationship
>
> is just nasty in IMHO. I would prefer a POST to
> api/v2/operatingsystems/24/architectures which either does a CREATE or
> FIND based on the presence of hte ID attribute. But, that is just me :)
>
> BTw... I am still waiting for the REST client which actually
> parses the url fragments which REST produces to "follow" the api"
>
> -- bk
>
>
To be specific and atomic, then you need to treat the many-to-many
relation
as its own resource. This is not the case with our example
PUT api/v2/operatingsystems/24
which update all the attributes AND associations for resource
operating
system #24
The RESTful way to only add or delete an association (similar to
what we
did for host_classes and hostgroup_classes) is this below: (Note
that BOTH
the architecture id and operating system id’s already exist)
Create a new association
POST api/v2/operatingsystems/24/architectures_operatingsystems -d
{‘id’: 1}
object created
{
‘id’: 555
’operatingsystem_id’: 24
’architecture_id’: 1
}
Delete an association
DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555
This is similar to what Bryan may thought of when he wrote
What about a
PUT api/v2/operatingsystems/24/architectures
But the issue here is that PUT requires an ID of a resource to update.
yeah… I should have put POST.
The ‘problem’ with the atomic restful way is that most 'simple’
API’s don’t
expose the database internals such as id #555 on a join table which is
meaningless to the user.
I would make it architectures. That way the join parrt is hidden a bit.
POST api/v2/operatingsystems/24/architectures -d {‘id’: 1}
This would be confusing, since in RESTful style, a POST on a
collection (architectures) creates a new architecture.
You are correct… but this for me is when the REST WILL SOLVE ALL
ISSUES argument starts to fail. Haveing a resource which is
is just nasty in IMHO. I would prefer a POST to
api/v2/operatingsystems/24/architectures which either does a CREATE or
FIND based on the presence of hte ID attribute. But, that is just me
BTw… I am still waiting for the REST client which actually
parses the url fragments which REST produces to “follow” the api"
– bk
I’d suggest something similar to what Bryan came up with
PUT api/v2/operatingsystems/24/add_architecture/2
PUT api/v2/operatingsystems/24/remove_architecture/2
The reason would be that the relation is not a resource but rather an
attribute. I’d use PUT as the operation is idempotent and from users
perspective it alters the os resource.
···
----- Original Message -----
> From: "Joseph Magen"
> To: foreman-dev@googlegroups.com
> Sent: Thursday, February 6, 2014 9:55:00 AM
> Subject: Re: [foreman-dev] Updating many-to-many relationships
>
> OK, I will do this
>
> > PUT api/v2/operatingsystems/24/add_architecture/2
> > PUT api/v2/operatingsystems/24/remove_architecture/2
>
>
>
> ----- Original Message -----
> > From: "Martin Bačovský"
> > To: foreman-dev@googlegroups.com
> > Sent: Thursday, February 6, 2014 4:48:02 PM
> > Subject: Re: [foreman-dev] Updating many-to-many relationships
> >
> > On 01/30/2014 02:31 PM, Bryan Kearney wrote:
> > > On 01/30/2014 08:19 AM, Joseph Magen wrote:
> > >> ----- Original Message -----
> > >>> From: "Bryan Kearney"
> > >>> To: foreman-dev@googlegroups.com
> > >>> Sent: Thursday, January 30, 2014 3:13:37 PM
> > >>> Subject: Re: [foreman-dev] Updating many-to-many relationships
> > >>>
> > >>> On 01/30/2014 02:42 AM, Joseph Magen wrote:
> > >>>> To be specific and atomic, then you need to treat the many-to-many
> > >>>> relation
> > >>>> as its own resource. This is not the case with our example
> > >>>>
> > >>>> PUT api/v2/operatingsystems/24
> > >>>>
> > >>>> which update all the attributes AND associations for resource
> > >>>> operating
> > >>>> system #24
> > >>>>
> > >>>> The RESTful way to only add or delete an association (similar to
> > >>>> what we
> > >>>> did for host_classes and hostgroup_classes) is this below: (Note
> > >>>> that BOTH
> > >>>> the architecture id and operating system id's already exist)
> > >>>>
> > >>>> Create a new association
> > >>>> POST api/v2/operatingsystems/24/architectures_operatingsystems -d
> > >>>> {'id': 1}
> > >>>>
> > >>>> object created
> > >>>> {
> > >>>> 'id': 555
> > >>>> 'operatingsystem_id': 24
> > >>>> 'architecture_id': 1
> > >>>> }
> > >>>>
> > >>>> Delete an association
> > >>>> DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555
> > >>>>
> > >>>> This is similar to what Bryan may thought of when he wrote
> > >>>>
> > >>>>> What about a
> > >>>>> PUT api/v2/operatingsystems/24/architectures
> > >>>>
> > >>>> But the issue here is that PUT requires an ID of a resource to update.
> > >>>
> > >>>
> > >>> yeah... I should have put POST.
> > >>>
> > >>>>
> > >>>> The 'problem' with the atomic restful way is that most 'simple'
> > >>>> API's don't
> > >>>> expose the database internals such as id #555 on a join table which is
> > >>>> meaningless to the user.
> > >>>
> > >>> I would make it architectures. That way the join parrt is hidden a bit.
> > >>
> > >>
> > >> POST api/v2/operatingsystems/24/architectures -d {'id': 1}
> > >>
> > >> This would be confusing, since in RESTful style, a POST on a
> > >> collection (architectures) creates a new architecture.
> > >
> > >
> > > You are correct.. but this for me is when the REST WILL SOLVE ALL
> > > ISSUES argument starts to fail. Haveing a resource which is
> > >
> > > api/v2/operatingsystems_architectures_relationship
> > >
> > > is just nasty in IMHO. I would prefer a POST to
> > > api/v2/operatingsystems/24/architectures which either does a CREATE or
> > > FIND based on the presence of hte ID attribute. But, that is just me :)
> > >
> > > BTw... I am still waiting for the REST client which actually
> > > parses the url fragments which REST produces to "follow" the api"
> > >
> > > -- bk
> > >
> > >
> > I'd suggest something similar to what Bryan came up with
> >
> > PUT api/v2/operatingsystems/24/add_architecture/2
> > PUT api/v2/operatingsystems/24/remove_architecture/2
> >
> > The reason would be that the relation is not a resource but rather an
> > attribute. I'd use PUT as the operation is idempotent and from users
> > perspective it alters the os resource.
> >
> > Makes sense?
> >
> > M
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
You can write the docs but wait until the feature is merged in 'develop' until you merge the docs in theforeman.org.
Can you also add this feature issue to redmine.
Thanks,
Joseph
···
----- Original Message -----
> From: "David Davis"
> To: foreman-dev@googlegroups.com
> Sent: Thursday, February 6, 2014 4:56:49 PM
> Subject: Re: [foreman-dev] Updating many-to-many relationships
>
> Should I add this to the documentation?
>
> David
>
> ----- Original Message -----
> > From: "Joseph Magen"
> > To: foreman-dev@googlegroups.com
> > Sent: Thursday, February 6, 2014 9:55:00 AM
> > Subject: Re: [foreman-dev] Updating many-to-many relationships
> >
> > OK, I will do this
> >
> > > PUT api/v2/operatingsystems/24/add_architecture/2
> > > PUT api/v2/operatingsystems/24/remove_architecture/2
> >
> >
> >
> > ----- Original Message -----
> > > From: "Martin Bačovský"
> > > To: foreman-dev@googlegroups.com
> > > Sent: Thursday, February 6, 2014 4:48:02 PM
> > > Subject: Re: [foreman-dev] Updating many-to-many relationships
> > >
> > > On 01/30/2014 02:31 PM, Bryan Kearney wrote:
> > > > On 01/30/2014 08:19 AM, Joseph Magen wrote:
> > > >> ----- Original Message -----
> > > >>> From: "Bryan Kearney"
> > > >>> To: foreman-dev@googlegroups.com
> > > >>> Sent: Thursday, January 30, 2014 3:13:37 PM
> > > >>> Subject: Re: [foreman-dev] Updating many-to-many relationships
> > > >>>
> > > >>> On 01/30/2014 02:42 AM, Joseph Magen wrote:
> > > >>>> To be specific and atomic, then you need to treat the many-to-many
> > > >>>> relation
> > > >>>> as its own resource. This is not the case with our example
> > > >>>>
> > > >>>> PUT api/v2/operatingsystems/24
> > > >>>>
> > > >>>> which update all the attributes AND associations for resource
> > > >>>> operating
> > > >>>> system #24
> > > >>>>
> > > >>>> The RESTful way to only add or delete an association (similar to
> > > >>>> what we
> > > >>>> did for host_classes and hostgroup_classes) is this below: (Note
> > > >>>> that BOTH
> > > >>>> the architecture id and operating system id's already exist)
> > > >>>>
> > > >>>> Create a new association
> > > >>>> POST api/v2/operatingsystems/24/architectures_operatingsystems -d
> > > >>>> {'id': 1}
> > > >>>>
> > > >>>> object created
> > > >>>> {
> > > >>>> 'id': 555
> > > >>>> 'operatingsystem_id': 24
> > > >>>> 'architecture_id': 1
> > > >>>> }
> > > >>>>
> > > >>>> Delete an association
> > > >>>> DELETE api/v2/operatingsystems/24/architectures_operatingsystems/555
> > > >>>>
> > > >>>> This is similar to what Bryan may thought of when he wrote
> > > >>>>
> > > >>>>> What about a
> > > >>>>> PUT api/v2/operatingsystems/24/architectures
> > > >>>>
> > > >>>> But the issue here is that PUT requires an ID of a resource to
> > > >>>> update.
> > > >>>
> > > >>>
> > > >>> yeah... I should have put POST.
> > > >>>
> > > >>>>
> > > >>>> The 'problem' with the atomic restful way is that most 'simple'
> > > >>>> API's don't
> > > >>>> expose the database internals such as id #555 on a join table which
> > > >>>> is
> > > >>>> meaningless to the user.
> > > >>>
> > > >>> I would make it architectures. That way the join parrt is hidden a
> > > >>> bit.
> > > >>
> > > >>
> > > >> POST api/v2/operatingsystems/24/architectures -d {'id': 1}
> > > >>
> > > >> This would be confusing, since in RESTful style, a POST on a
> > > >> collection (architectures) creates a new architecture.
> > > >
> > > >
> > > > You are correct.. but this for me is when the REST WILL SOLVE ALL
> > > > ISSUES argument starts to fail. Haveing a resource which is
> > > >
> > > > api/v2/operatingsystems_architectures_relationship
> > > >
> > > > is just nasty in IMHO. I would prefer a POST to
> > > > api/v2/operatingsystems/24/architectures which either does a CREATE or
> > > > FIND based on the presence of hte ID attribute. But, that is just me :)
> > > >
> > > > BTw... I am still waiting for the REST client which actually
> > > > parses the url fragments which REST produces to "follow" the api"
> > > >
> > > >
> > > > -- bk
> > > >
> > > >
> > > I'd suggest something similar to what Bryan came up with
> > >
> > > PUT api/v2/operatingsystems/24/add_architecture/2
> > > PUT api/v2/operatingsystems/24/remove_architecture/2
> > >
> > > The reason would be that the relation is not a resource but rather an
> > > attribute. I'd use PUT as the operation is idempotent and from users
> > > perspective it alters the os resource.
> > >
> > > Makes sense?
> > >
> > > M
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "foreman-dev" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
fixes #5780 - API v2 - RESTful way to add/remove many-to-many association one at a time rather than passing all id's
It is part of the PR to add's nested routes.
I only included adding/removing many-to-many relationship between architectures & operating systems. If we all agree, then I'll add the other n:n associations.
In short, the RESTful way is this
POST /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
DELETE /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
However, I changed it slightly to
POST /operatingsystems/:operatingsystem_id/architectures/:architecture_id/add
DELETE /operatingsystems/:operatingsystem_id/architectures/:architecture_id/remove
I don't see the advantage of exposing 'architecture_operatingsystems' in the path. Even tough the keywords such as "add, create, delete, remove" usually don't appear in the URL as they are inferred by HTTP VERBS, I think in this case, it's more intuitive than having a meaninglessly join-table name.
What are your thoughts?
Joseph
Red Hat Engineering
···
----- Original Message -----
> From: "Joseph Magen"
> To: foreman-dev@googlegroups.com
> Sent: Thursday, February 6, 2014 5:06:04 PM
> Subject: Re: [foreman-dev] Updating many-to-many relationships
>
> You can write the docs but wait until the feature is merged in 'develop'
> until you merge the docs in theforeman.org.
>
> Can you also add this feature issue to redmine.
>
> Thanks,
>
> Joseph
>
>
> ----- Original Message -----
> > From: "David Davis"
> > To: foreman-dev@googlegroups.com
> > Sent: Thursday, February 6, 2014 4:56:49 PM
> > Subject: Re: [foreman-dev] Updating many-to-many relationships
> >
> > Should I add this to the documentation?
> >
> > David
> >
> > ----- Original Message -----
> > > From: "Joseph Magen"
> > > To: foreman-dev@googlegroups.com
> > > Sent: Thursday, February 6, 2014 9:55:00 AM
> > > Subject: Re: [foreman-dev] Updating many-to-many relationships
> > >
> > > OK, I will do this
> > >
> > > > PUT api/v2/operatingsystems/24/add_architecture/2
> > > > PUT api/v2/operatingsystems/24/remove_architecture/2
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Martin Bačovský"
> > > > To: foreman-dev@googlegroups.com
> > > > Sent: Thursday, February 6, 2014 4:48:02 PM
> > > > Subject: Re: [foreman-dev] Updating many-to-many relationships
> > > >
> > > > On 01/30/2014 02:31 PM, Bryan Kearney wrote:
> > > > > On 01/30/2014 08:19 AM, Joseph Magen wrote:
> > > > >> ----- Original Message -----
> > > > >>> From: "Bryan Kearney"
> > > > >>> To: foreman-dev@googlegroups.com
> > > > >>> Sent: Thursday, January 30, 2014 3:13:37 PM
> > > > >>> Subject: Re: [foreman-dev] Updating many-to-many relationships
> > > > >>>
> > > > >>> On 01/30/2014 02:42 AM, Joseph Magen wrote:
> > > > >>>> To be specific and atomic, then you need to treat the many-to-many
> > > > >>>> relation
> > > > >>>> as its own resource. This is not the case with our example
> > > > >>>>
> > > > >>>> PUT api/v2/operatingsystems/24
> > > > >>>>
> > > > >>>> which update all the attributes AND associations for resource
> > > > >>>> operating
> > > > >>>> system #24
> > > > >>>>
> > > > >>>> The RESTful way to only add or delete an association (similar to
> > > > >>>> what we
> > > > >>>> did for host_classes and hostgroup_classes) is this below: (Note
> > > > >>>> that BOTH
> > > > >>>> the architecture id and operating system id's already exist)
> > > > >>>>
> > > > >>>> Create a new association
> > > > >>>> POST api/v2/operatingsystems/24/architectures_operatingsystems -d
> > > > >>>> {'id': 1}
> > > > >>>>
> > > > >>>> object created
> > > > >>>> {
> > > > >>>> 'id': 555
> > > > >>>> 'operatingsystem_id': 24
> > > > >>>> 'architecture_id': 1
> > > > >>>> }
> > > > >>>>
> > > > >>>> Delete an association
> > > > >>>> DELETE
> > > > >>>> api/v2/operatingsystems/24/architectures_operatingsystems/555
> > > > >>>>
> > > > >>>> This is similar to what Bryan may thought of when he wrote
> > > > >>>>
> > > > >>>>> What about a
> > > > >>>>> PUT api/v2/operatingsystems/24/architectures
> > > > >>>>
> > > > >>>> But the issue here is that PUT requires an ID of a resource to
> > > > >>>> update.
> > > > >>>
> > > > >>>
> > > > >>> yeah... I should have put POST.
> > > > >>>
> > > > >>>>
> > > > >>>> The 'problem' with the atomic restful way is that most 'simple'
> > > > >>>> API's don't
> > > > >>>> expose the database internals such as id #555 on a join table
> > > > >>>> which
> > > > >>>> is
> > > > >>>> meaningless to the user.
> > > > >>>
> > > > >>> I would make it architectures. That way the join parrt is hidden a
> > > > >>> bit.
> > > > >>
> > > > >>
> > > > >> POST api/v2/operatingsystems/24/architectures -d {'id': 1}
> > > > >>
> > > > >> This would be confusing, since in RESTful style, a POST on a
> > > > >> collection (architectures) creates a new architecture.
> > > > >
> > > > >
> > > > > You are correct.. but this for me is when the REST WILL SOLVE ALL
> > > > > ISSUES argument starts to fail. Haveing a resource which is
> > > > >
> > > > > api/v2/operatingsystems_architectures_relationship
> > > > >
> > > > > is just nasty in IMHO. I would prefer a POST to
> > > > > api/v2/operatingsystems/24/architectures which either does a CREATE
> > > > > or
> > > > > FIND based on the presence of hte ID attribute. But, that is just me
> > > > > :)
> > > > >
> > > > > BTw... I am still waiting for the REST client which actually
> > > > > parses the url fragments which REST produces to "follow" the api"
> > > > >
> > > > >
> > > > > -- bk
> > > > >
> > > > >
> > > > I'd suggest something similar to what Bryan came up with
> > > >
> > > > PUT api/v2/operatingsystems/24/add_architecture/2
> > > > PUT api/v2/operatingsystems/24/remove_architecture/2
> > > >
> > > > The reason would be that the relation is not a resource but rather an
> > > > attribute. I'd use PUT as the operation is idempotent and from users
> > > > perspective it alters the os resource.
> > > >
> > > > Makes sense?
> > > >
> > > > M
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups
> > > > "foreman-dev" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an
> > > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > > For more options, visit https://groups.google.com/groups/opt_out.
> > > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "foreman-dev" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
> Reviving an old thread
>
> I push a new commit to https://github.com/theforeman/foreman/pull/1068
> entited
>
> fixes #5780 - API v2 - RESTful way to add/remove many-to-many association
> one at a time rather than passing all id's
>
> It is part of the PR to add's nested routes.
>
> I only included adding/removing many-to-many relationship between
> architectures & operating systems. If we all agree, then I'll add the other
> n:n associations.
>
> In short, the RESTful way is this
>
> POST
> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
> DELETE
> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
>
> However, I changed it slightly to
>
> POST
> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/add
> DELETE
> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/remove
Wouldn't be the the RESTful way?:
POST /operatingsystems/:operatingsystem_id/architectures { "architecture_id": 1}
DELETE /operatingsystems/:operatingsystem_id/architectures/:architecture_id
POST and DELETE already should have the meaning of adding/removing the resource
I might have missed the discussion around that, so somebody might just update
me on the reasons for choosing this path?
Thanks
– Ivan
···
----- Original Message -----
I don’t see the advantage of exposing ‘architecture_operatingsystems’ in the
path. Even tough the keywords such as “add, create, delete, remove” usually
don’t appear in the URL as they are inferred by HTTP VERBS, I think in this
case, it’s more intuitive than having a meaninglessly join-table name.
To be specific and atomic, then you need to treat the
many-to-many
relation
as its own resource. This is not the case with our example
PUT api/v2/operatingsystems/24
which update all the attributes AND associations for resource
operating
system #24
The RESTful way to only add or delete an association (similar to
what we
did for host_classes and hostgroup_classes) is this below: (Note
that BOTH
the architecture id and operating system id’s already exist)
Create a new association
POST api/v2/operatingsystems/24/architectures_operatingsystems
-d
{‘id’: 1}
object created
{
‘id’: 555
’operatingsystem_id’: 24
’architecture_id’: 1
}
Delete an association
DELETE
api/v2/operatingsystems/24/architectures_operatingsystems/555
This is similar to what Bryan may thought of when he wrote
What about a
PUT api/v2/operatingsystems/24/architectures
But the issue here is that PUT requires an ID of a resource to
update.
yeah… I should have put POST.
The ‘problem’ with the atomic restful way is that most 'simple’
API’s don’t
expose the database internals such as id #555 on a join table
which
is
meaningless to the user.
I would make it architectures. That way the join parrt is hidden
a
bit.
POST api/v2/operatingsystems/24/architectures -d {‘id’: 1}
This would be confusing, since in RESTful style, a POST on a
collection (architectures) creates a new architecture.
You are correct… but this for me is when the REST WILL SOLVE ALL
ISSUES argument starts to fail. Haveing a resource which is
is just nasty in IMHO. I would prefer a POST to
api/v2/operatingsystems/24/architectures which either does a CREATE
or
FIND based on the presence of hte ID attribute. But, that is just
me
BTw… I am still waiting for the REST client which actually
parses the url fragments which REST produces to “follow” the api"
– bk
I’d suggest something similar to what Bryan came up with
PUT api/v2/operatingsystems/24/add_architecture/2
PUT api/v2/operatingsystems/24/remove_architecture/2
The reason would be that the relation is not a resource but rather an
attribute. I’d use PUT as the operation is idempotent and from users
perspective it alters the os resource.
···
----- Original Message -----
> From: "Joseph Magen"
> To: foreman-dev@googlegroups.com
> Sent: Sunday, May 18, 2014 6:01:36 PM
> Subject: Re: [foreman-dev] Updating many-to-many relationships
>
> Reviving an old thread
>
> I push a new commit to https://github.com/theforeman/foreman/pull/1068
> entited
>
> fixes #5780 - API v2 - RESTful way to add/remove many-to-many association
> one at a time rather than passing all id's
>
> It is part of the PR to add's nested routes.
>
> I only included adding/removing many-to-many relationship between
> architectures & operating systems. If we all agree, then I'll add the other
> n:n associations.
>
> In short, the RESTful way is this
>
> POST
> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
> DELETE
> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
>
> However, I changed it slightly to
>
> POST
> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/add
> DELETE
> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/remove
>
> I don't see the advantage of exposing 'architecture_operatingsystems' in the
> path. Even tough the keywords such as "add, create, delete, remove" usually
> don't appear in the URL as they are inferred by HTTP VERBS, I think in this
> case, it's more intuitive than having a meaninglessly join-table name.
>
> What are your thoughts?
>
> Joseph
> Red Hat Engineering
>
>
>
> ----- Original Message -----
> > From: "Joseph Magen"
> > To: foreman-dev@googlegroups.com
> > Sent: Thursday, February 6, 2014 5:06:04 PM
> > Subject: Re: [foreman-dev] Updating many-to-many relationships
> >
> > You can write the docs but wait until the feature is merged in 'develop'
> > until you merge the docs in theforeman.org.
> >
> > Can you also add this feature issue to redmine.
> >
> > Thanks,
> >
> > Joseph
> >
> >
> > ----- Original Message -----
> > > From: "David Davis"
> > > To: foreman-dev@googlegroups.com
> > > Sent: Thursday, February 6, 2014 4:56:49 PM
> > > Subject: Re: [foreman-dev] Updating many-to-many relationships
> > >
> > > Should I add this to the documentation?
> > >
> > > David
> > >
> > > ----- Original Message -----
> > > > From: "Joseph Magen"
> > > > To: foreman-dev@googlegroups.com
> > > > Sent: Thursday, February 6, 2014 9:55:00 AM
> > > > Subject: Re: [foreman-dev] Updating many-to-many relationships
> > > >
> > > > OK, I will do this
> > > >
> > > > > PUT api/v2/operatingsystems/24/add_architecture/2
> > > > > PUT api/v2/operatingsystems/24/remove_architecture/2
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Martin Bačovský"
> > > > > To: foreman-dev@googlegroups.com
> > > > > Sent: Thursday, February 6, 2014 4:48:02 PM
> > > > > Subject: Re: [foreman-dev] Updating many-to-many relationships
> > > > >
> > > > > On 01/30/2014 02:31 PM, Bryan Kearney wrote:
> > > > > > On 01/30/2014 08:19 AM, Joseph Magen wrote:
> > > > > >> ----- Original Message -----
> > > > > >>> From: "Bryan Kearney"
> > > > > >>> To: foreman-dev@googlegroups.com
> > > > > >>> Sent: Thursday, January 30, 2014 3:13:37 PM
> > > > > >>> Subject: Re: [foreman-dev] Updating many-to-many relationships
> > > > > >>>
> > > > > >>> On 01/30/2014 02:42 AM, Joseph Magen wrote:
> > > > > >>>> To be specific and atomic, then you need to treat the
> > > > > >>>> many-to-many
> > > > > >>>> relation
> > > > > >>>> as its own resource. This is not the case with our example
> > > > > >>>>
> > > > > >>>> PUT api/v2/operatingsystems/24
> > > > > >>>>
> > > > > >>>> which update all the attributes AND associations for resource
> > > > > >>>> operating
> > > > > >>>> system #24
> > > > > >>>>
> > > > > >>>> The RESTful way to only add or delete an association (similar to
> > > > > >>>> what we
> > > > > >>>> did for host_classes and hostgroup_classes) is this below: (Note
> > > > > >>>> that BOTH
> > > > > >>>> the architecture id and operating system id's already exist)
> > > > > >>>>
> > > > > >>>> Create a new association
> > > > > >>>> POST api/v2/operatingsystems/24/architectures_operatingsystems
> > > > > >>>> -d
> > > > > >>>> {'id': 1}
> > > > > >>>>
> > > > > >>>> object created
> > > > > >>>> {
> > > > > >>>> 'id': 555
> > > > > >>>> 'operatingsystem_id': 24
> > > > > >>>> 'architecture_id': 1
> > > > > >>>> }
> > > > > >>>>
> > > > > >>>> Delete an association
> > > > > >>>> DELETE
> > > > > >>>> api/v2/operatingsystems/24/architectures_operatingsystems/555
> > > > > >>>>
> > > > > >>>> This is similar to what Bryan may thought of when he wrote
> > > > > >>>>
> > > > > >>>>> What about a
> > > > > >>>>> PUT api/v2/operatingsystems/24/architectures
> > > > > >>>>
> > > > > >>>> But the issue here is that PUT requires an ID of a resource to
> > > > > >>>> update.
> > > > > >>>
> > > > > >>>
> > > > > >>> yeah... I should have put POST.
> > > > > >>>
> > > > > >>>>
> > > > > >>>> The 'problem' with the atomic restful way is that most 'simple'
> > > > > >>>> API's don't
> > > > > >>>> expose the database internals such as id #555 on a join table
> > > > > >>>> which
> > > > > >>>> is
> > > > > >>>> meaningless to the user.
> > > > > >>>
> > > > > >>> I would make it architectures. That way the join parrt is hidden
> > > > > >>> a
> > > > > >>> bit.
> > > > > >>
> > > > > >>
> > > > > >> POST api/v2/operatingsystems/24/architectures -d {'id': 1}
> > > > > >>
> > > > > >> This would be confusing, since in RESTful style, a POST on a
> > > > > >> collection (architectures) creates a new architecture.
> > > > > >
> > > > > >
> > > > > > You are correct.. but this for me is when the REST WILL SOLVE ALL
> > > > > > ISSUES argument starts to fail. Haveing a resource which is
> > > > > >
> > > > > > api/v2/operatingsystems_architectures_relationship
> > > > > >
> > > > > > is just nasty in IMHO. I would prefer a POST to
> > > > > > api/v2/operatingsystems/24/architectures which either does a CREATE
> > > > > > or
> > > > > > FIND based on the presence of hte ID attribute. But, that is just
> > > > > > me
> > > > > > :)
> > > > > >
> > > > > > BTw... I am still waiting for the REST client which actually
> > > > > > parses the url fragments which REST produces to "follow" the api"
> > > > > >
> > > > > >
> > > > > > -- bk
> > > > > >
> > > > > >
> > > > > I'd suggest something similar to what Bryan came up with
> > > > >
> > > > > PUT api/v2/operatingsystems/24/add_architecture/2
> > > > > PUT api/v2/operatingsystems/24/remove_architecture/2
> > > > >
> > > > > The reason would be that the relation is not a resource but rather an
> > > > > attribute. I'd use PUT as the operation is idempotent and from users
> > > > > perspective it alters the os resource.
> > > > >
> > > > > Makes sense?
> > > > >
> > > > > M
> > > > >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups
> > > > > "foreman-dev" group.
> > > > > To unsubscribe from this group and stop receiving emails from it,
> > > > > send
> > > > > an
> > > > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > > > For more options, visit https://groups.google.com/groups/opt_out.
> > > > >
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google
> > > > Groups
> > > > "foreman-dev" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send
> > > > an
> > > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > > For more options, visit https://groups.google.com/groups/opt_out.
> > > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "foreman-dev" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
>
>
> > Reviving an old thread
> >
> > I push a new commit to https://github.com/theforeman/foreman/pull/1068
> > entited
> >
> > fixes #5780 - API v2 - RESTful way to add/remove many-to-many
> > association
> > one at a time rather than passing all id's
> >
> > It is part of the PR to add's nested routes.
> >
> > I only included adding/removing many-to-many relationship between
> > architectures & operating systems. If we all agree, then I'll add the other
> > n:n associations.
> >
> > In short, the RESTful way is this
> >
> > POST
> > /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
> > DELETE
> > /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
> >
> > However, I changed it slightly to
> >
> > POST
> > /operatingsystems/:operatingsystem_id/architectures/:architecture_id/add
> > DELETE
> > /operatingsystems/:operatingsystem_id/architectures/:architecture_id/remove
>
> Wouldn't be the the RESTful way?:
>
> POST /operatingsystems/:operatingsystem_id/architectures { "architecture_id":
> 1}
> DELETE /operatingsystems/:operatingsystem_id/architectures/:architecture_id
>
> POST and DELETE already should have the meaning of adding/removing the
> resource
>
> I might have missed the discussion around that, so somebody might just update
> me on the reasons for choosing this path?
>
> Thanks
>
> – Ivan
>
> >
> > I don't see the advantage of exposing 'architecture_operatingsystems' in
> > the
> > path. Even tough the keywords such as "add, create, delete, remove" usually
> > don't appear in the URL as they are inferred by HTTP VERBS, I think in this
> > case, it's more intuitive than having a meaninglessly join-table name.
+1 on not exposing the ArchitectureOperatingSystem as a resource.
···
----- Original Message -----
> ----- Original Message -----
To be specific and atomic, then you need to treat the
many-to-many
relation
as its own resource. This is not the case with our example
PUT api/v2/operatingsystems/24
which update all the attributes AND associations for resource
operating
system #24
The RESTful way to only add or delete an association (similar
to
what we
did for host_classes and hostgroup_classes) is this below:
(Note
that BOTH
the architecture id and operating system id’s already exist)
Create a new association
POST api/v2/operatingsystems/24/architectures_operatingsystems
-d
{‘id’: 1}
object created
{
‘id’: 555
’operatingsystem_id’: 24
’architecture_id’: 1
}
Delete an association
DELETE
api/v2/operatingsystems/24/architectures_operatingsystems/555
This is similar to what Bryan may thought of when he wrote
What about a
PUT api/v2/operatingsystems/24/architectures
But the issue here is that PUT requires an ID of a resource to
update.
yeah… I should have put POST.
The ‘problem’ with the atomic restful way is that most
’simple’
API’s don’t
expose the database internals such as id #555 on a join table
which
is
meaningless to the user.
I would make it architectures. That way the join parrt is
hidden
a
bit.
POST api/v2/operatingsystems/24/architectures -d {‘id’: 1}
This would be confusing, since in RESTful style, a POST on a
collection (architectures) creates a new architecture.
You are correct… but this for me is when the REST WILL SOLVE ALL
ISSUES argument starts to fail. Haveing a resource which is
is just nasty in IMHO. I would prefer a POST to
api/v2/operatingsystems/24/architectures which either does a
CREATE
or
FIND based on the presence of hte ID attribute. But, that is just
me
BTw… I am still waiting for the REST client which
actually
parses the url fragments which REST produces to “follow” the api"
– bk
I’d suggest something similar to what Bryan came up with
PUT api/v2/operatingsystems/24/add_architecture/2
PUT api/v2/operatingsystems/24/remove_architecture/2
The reason would be that the relation is not a resource but rather
an
attribute. I’d use PUT as the operation is idempotent and from
users
perspective it alters the os resource.
>
>
>> Reviving an old thread
>>
>> I push a new commit to https://github.com/theforeman/foreman/pull/1068
>> entited
>>
>> fixes #5780 - API v2 - RESTful way to add/remove many-to-many association
>> one at a time rather than passing all id's
>>
>> It is part of the PR to add's nested routes.
>>
>> I only included adding/removing many-to-many relationship between
>> architectures & operating systems. If we all agree, then I'll add the other
>> n:n associations.
>>
>> In short, the RESTful way is this
>>
>> POST
>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
>> DELETE
>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
>>
>> However, I changed it slightly to
>>
>> POST
>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/add
>> DELETE
>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/remove
>
> Wouldn't be the the RESTful way?:
>
> POST /operatingsystems/:operatingsystem_id/architectures { "architecture_id": 1}
> DELETE /operatingsystems/:operatingsystem_id/architectures/:architecture_id
>
> POST and DELETE already should have the meaning of adding/removing the resource
+1
···
On 19.05.14 9:44, Ivan Necas wrote:
> ----- Original Message -----
I might have missed the discussion around that, so somebody might just update
me on the reasons for choosing this path?
Thanks
– Ivan
I don’t see the advantage of exposing ‘architecture_operatingsystems’ in the
path. Even tough the keywords such as “add, create, delete, remove” usually
don’t appear in the URL as they are inferred by HTTP VERBS, I think in this
case, it’s more intuitive than having a meaninglessly join-table name.
To be specific and atomic, then you need to treat the
many-to-many
relation
as its own resource. This is not the case with our example
PUT api/v2/operatingsystems/24
which update all the attributes AND associations for resource
operating
system #24
The RESTful way to only add or delete an association (similar to
what we
did for host_classes and hostgroup_classes) is this below: (Note
that BOTH
the architecture id and operating system id’s already exist)
Create a new association
POST api/v2/operatingsystems/24/architectures_operatingsystems
-d
{‘id’: 1}
object created
{
‘id’: 555
’operatingsystem_id’: 24
’architecture_id’: 1
}
Delete an association
DELETE
api/v2/operatingsystems/24/architectures_operatingsystems/555
This is similar to what Bryan may thought of when he wrote
What about a
PUT api/v2/operatingsystems/24/architectures
But the issue here is that PUT requires an ID of a resource to
update.
yeah… I should have put POST.
The ‘problem’ with the atomic restful way is that most 'simple’
API’s don’t
expose the database internals such as id #555 on a join table
which
is
meaningless to the user.
I would make it architectures. That way the join parrt is hidden
a
bit.
POST api/v2/operatingsystems/24/architectures -d {‘id’: 1}
This would be confusing, since in RESTful style, a POST on a
collection (architectures) creates a new architecture.
You are correct… but this for me is when the REST WILL SOLVE ALL
ISSUES argument starts to fail. Haveing a resource which is
is just nasty in IMHO. I would prefer a POST to
api/v2/operatingsystems/24/architectures which either does a CREATE
or
FIND based on the presence of hte ID attribute. But, that is just
me
BTw… I am still waiting for the REST client which actually
parses the url fragments which REST produces to “follow” the api"
– bk
I’d suggest something similar to what Bryan came up with
PUT api/v2/operatingsystems/24/add_architecture/2
PUT api/v2/operatingsystems/24/remove_architecture/2
The reason would be that the relation is not a resource but rather an
attribute. I’d use PUT as the operation is idempotent and from users
perspective it alters the os resource.
>
>> Reviving an old thread
>>
>> I push a new commit to https://github.com/theforeman/foreman/pull/1068
>> entited
>>
>> fixes #5780 - API v2 - RESTful way to add/remove many-to-many association
>> one at a time rather than passing all id's
>>
>> It is part of the PR to add's nested routes.
>>
>> I only included adding/removing many-to-many relationship between
>> architectures & operating systems. If we all agree, then I'll add the other
>> n:n associations.
>>
>> In short, the RESTful way is this
>>
>> POST
>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
>> DELETE
>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
>>
>> However, I changed it slightly to
>>
>> POST
>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/add
>> DELETE
>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/remove
> Wouldn't be the the RESTful way?:
>
> POST /operatingsystems/:operatingsystem_id/architectures { "architecture_id": 1}
> DELETE /operatingsystems/:operatingsystem_id/architectures/:architecture_id
>
> POST and DELETE already should have the meaning of adding/removing the resource
>
> I might have missed the discussion around that, so somebody might just update
> me on the reasons for choosing this path?
>
> Thanks
>
> – Ivan
>
+1 for Ivan's suggestion or we can use
PUT api/v2/operatingsystems/24/add_architecture/2
PUT api/v2/operatingsystems/24/remove_architecture/2
if don't see os-architecture relationship as a resource.
I'm okay with any of these two
M
···
On 05/19/2014 09:44 AM, Ivan Necas wrote:
> ----- Original Message -----
I don’t see the advantage of exposing ‘architecture_operatingsystems’ in the
path. Even tough the keywords such as “add, create, delete, remove” usually
don’t appear in the URL as they are inferred by HTTP VERBS, I think in this
case, it’s more intuitive than having a meaninglessly join-table name.
To be specific and atomic, then you need to treat the
many-to-many
relation
as its own resource. This is not the case with our example
PUT api/v2/operatingsystems/24
which update all the attributes AND associations for resource
operating
system #24
The RESTful way to only add or delete an association (similar to
what we
did for host_classes and hostgroup_classes) is this below: (Note
that BOTH
the architecture id and operating system id’s already exist)
Create a new association
POST api/v2/operatingsystems/24/architectures_operatingsystems
-d
{‘id’: 1}
object created
{
‘id’: 555
’operatingsystem_id’: 24
’architecture_id’: 1
}
Delete an association
DELETE
api/v2/operatingsystems/24/architectures_operatingsystems/555
This is similar to what Bryan may thought of when he wrote
What about a
PUT api/v2/operatingsystems/24/architectures
But the issue here is that PUT requires an ID of a resource to
update.
yeah… I should have put POST.
The ‘problem’ with the atomic restful way is that most 'simple’
API’s don’t
expose the database internals such as id #555 on a join table
which
is
meaningless to the user.
I would make it architectures. That way the join parrt is hidden
a
bit.
POST api/v2/operatingsystems/24/architectures -d {‘id’: 1}
This would be confusing, since in RESTful style, a POST on a
collection (architectures) creates a new architecture.
You are correct… but this for me is when the REST WILL SOLVE ALL
ISSUES argument starts to fail. Haveing a resource which is
is just nasty in IMHO. I would prefer a POST to
api/v2/operatingsystems/24/architectures which either does a CREATE
or
FIND based on the presence of hte ID attribute. But, that is just
me
BTw… I am still waiting for the REST client which actually
parses the url fragments which REST produces to “follow” the api"
– bk
I’d suggest something similar to what Bryan came up with
PUT api/v2/operatingsystems/24/add_architecture/2
PUT api/v2/operatingsystems/24/remove_architecture/2
The reason would be that the relation is not a resource but rather an
attribute. I’d use PUT as the operation is idempotent and from users
perspective it alters the os resource.
>
>>
>>
>>> Reviving an old thread
>>>
>>> I push a new commit to https://github.com/theforeman/foreman/pull/1068
>>> entited
>>>
>>> fixes #5780 - API v2 - RESTful way to add/remove many-to-many
>>> association
>>> one at a time rather than passing all id's
>>>
>>> It is part of the PR to add's nested routes.
>>>
>>> I only included adding/removing many-to-many relationship between
>>> architectures & operating systems. If we all agree, then I'll add the other
>>> n:n associations.
>>>
>>> In short, the RESTful way is this
>>>
>>> POST
>>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
>>> DELETE
>>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
>>>
>>> However, I changed it slightly to
>>>
>>> POST
>>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/add
>>> DELETE
>>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/remove
>>
>> Wouldn't be the the RESTful way?:
>>
>> POST /operatingsystems/:operatingsystem_id/architectures { "architecture_id":
>> 1}
>> DELETE /operatingsystems/:operatingsystem_id/architectures/:architecture_id
>>
>> POST and DELETE already should have the meaning of adding/removing the
>> resource
I know rest purists might argue but I find Ivan's routes more intuitive.
Just out of my curiosity, what way is used in katello at the moment?
Ideally we should be converging to a consistent route style.
Joseph, is there any "api guidelines" document, we could refer to, please?
>>
>> I might have missed the discussion around that, so somebody might just update
>> me on the reasons for choosing this path?
>>
>> Thanks
>>
>> – Ivan
>>
>>>
>>> I don't see the advantage of exposing 'architecture_operatingsystems' in
>>> the
>>> path. Even tough the keywords such as "add, create, delete, remove" usually
>>> don't appear in the URL as they are inferred by HTTP VERBS, I think in this
>>> case, it's more intuitive than having a meaninglessly join-table name.
>
> +1 on not exposing the ArchitectureOperatingSystem as a resource.
+1 let's not expose them, please.
···
On 05/19/2014 09:47 AM, Ivan Necas wrote:
> ----- Original Message -----
>> ----- Original Message -----
To be specific and atomic, then you need to treat the
many-to-many
relation
as its own resource. This is not the case with our example
PUT api/v2/operatingsystems/24
which update all the attributes AND associations for resource
operating
system #24
The RESTful way to only add or delete an association (similar
to
what we
did for host_classes and hostgroup_classes) is this below:
(Note
that BOTH
the architecture id and operating system id’s already exist)
Create a new association
POST api/v2/operatingsystems/24/architectures_operatingsystems
-d
{‘id’: 1}
object created
{
‘id’: 555
’operatingsystem_id’: 24
’architecture_id’: 1
}
Delete an association
DELETE
api/v2/operatingsystems/24/architectures_operatingsystems/555
This is similar to what Bryan may thought of when he wrote
What about a
PUT api/v2/operatingsystems/24/architectures
But the issue here is that PUT requires an ID of a resource to
update.
yeah… I should have put POST.
The ‘problem’ with the atomic restful way is that most
’simple’
API’s don’t
expose the database internals such as id #555 on a join table
which
is
meaningless to the user.
I would make it architectures. That way the join parrt is
hidden
a
bit.
POST api/v2/operatingsystems/24/architectures -d {‘id’: 1}
This would be confusing, since in RESTful style, a POST on a
collection (architectures) creates a new architecture.
You are correct… but this for me is when the REST WILL SOLVE ALL
ISSUES argument starts to fail. Haveing a resource which is
is just nasty in IMHO. I would prefer a POST to
api/v2/operatingsystems/24/architectures which either does a
CREATE
or
FIND based on the presence of hte ID attribute. But, that is just
me
BTw… I am still waiting for the REST client which
actually
parses the url fragments which REST produces to “follow” the api"
– bk
I’d suggest something similar to what Bryan came up with
PUT api/v2/operatingsystems/24/add_architecture/2
PUT api/v2/operatingsystems/24/remove_architecture/2
The reason would be that the relation is not a resource but rather
an
attribute. I’d use PUT as the operation is idempotent and from
users
perspective it alters the os resource.
In Katello, we do it two ways. We support the foreman/hammer method:
POST /operatingsystems/:operatingsystem_id {"architecture_ids": [1,2,3]}
DELETE /operatingsystems/:operatingsystem_id {"architecture_ids": [1,2,3]}
And we have a way to add/remove individual items:
PUT /operatingsystems/24/add_architecture/2
DELETE /operatingsystems/24/remove_architecture/2
David
···
----- Original Message -----
> From: "Tomas Strachota"
> To: foreman-dev@googlegroups.com
> Sent: Monday, May 19, 2014 5:09:19 AM
> Subject: Re: [foreman-dev] Updating many-to-many relationships
>
> On 05/19/2014 09:47 AM, Ivan Necas wrote:
> >
> > ----- Original Message -----
> >>
> >>
> >> ----- Original Message -----
> >>> Reviving an old thread
> >>>
> >>> I push a new commit to https://github.com/theforeman/foreman/pull/1068
> >>> entited
> >>>
> >>> fixes #5780 - API v2 - RESTful way to add/remove many-to-many
> >>> association
> >>> one at a time rather than passing all id's
> >>>
> >>> It is part of the PR to add's nested routes.
> >>>
> >>> I only included adding/removing many-to-many relationship between
> >>> architectures & operating systems. If we all agree, then I'll add the
> >>> other
> >>> n:n associations.
> >>>
> >>> In short, the RESTful way is this
> >>>
> >>> POST
> >>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
> >>> DELETE
> >>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
> >>>
> >>> However, I changed it slightly to
> >>>
> >>> POST
> >>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/add
> >>> DELETE
> >>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/remove
> >>
> >> Wouldn't be the the RESTful way?:
> >>
> >> POST /operatingsystems/:operatingsystem_id/architectures {
> >> "architecture_id":
> >> 1}
> >> DELETE
> >> /operatingsystems/:operatingsystem_id/architectures/:architecture_id
> >>
> >> POST and DELETE already should have the meaning of adding/removing the
> >> resource
>
> I know rest purists might argue but I find Ivan's routes more intuitive.
>
> Just out of my curiosity, what way is used in katello at the moment?
> Ideally we should be converging to a consistent route style.
>
> Joseph, is there any "api guidelines" document, we could refer to, please?
>
> >>
> >> I might have missed the discussion around that, so somebody might just
> >> update
> >> me on the reasons for choosing this path?
> >>
> >> Thanks
> >>
> >> -- Ivan
> >>
> >>>
> >>> I don't see the advantage of exposing 'architecture_operatingsystems' in
> >>> the
> >>> path. Even tough the keywords such as "add, create, delete, remove"
> >>> usually
> >>> don't appear in the URL as they are inferred by HTTP VERBS, I think in
> >>> this
> >>> case, it's more intuitive than having a meaninglessly join-table name.
> >
> > +1 on not exposing the ArchitectureOperatingSystem as a resource.
>
> +1 let's not expose them, please.
>
> >
> >>>
> >>> What are your thoughts?
> >>>
> >>> Joseph
> >>> Red Hat Engineering
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Joseph Magen"
> >>>> To: foreman-dev@googlegroups.com
> >>>> Sent: Thursday, February 6, 2014 5:06:04 PM
> >>>> Subject: Re: [foreman-dev] Updating many-to-many relationships
> >>>>
> >>>> You can write the docs but wait until the feature is merged in 'develop'
> >>>> until you merge the docs in theforeman.org.
> >>>>
> >>>> Can you also add this feature issue to redmine.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Joseph
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "David Davis"
> >>>>> To: foreman-dev@googlegroups.com
> >>>>> Sent: Thursday, February 6, 2014 4:56:49 PM
> >>>>> Subject: Re: [foreman-dev] Updating many-to-many relationships
> >>>>>
> >>>>> Should I add this to the documentation?
> >>>>>
> >>>>> David
> >>>>>
> >>>>> ----- Original Message -----
> >>>>> > From: "Joseph Magen"
> >>>>> > To: foreman-dev@googlegroups.com
> >>>>> > Sent: Thursday, February 6, 2014 9:55:00 AM
> >>>>> > Subject: Re: [foreman-dev] Updating many-to-many relationships
> >>>>> >
> >>>>> > OK, I will do this
> >>>>> >
> >>>>> > > PUT api/v2/operatingsystems/24/add_architecture/2
> >>>>> > > PUT api/v2/operatingsystems/24/remove_architecture/2
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> > ----- Original Message -----
> >>>>> > > From: "Martin Bačovský"
> >>>>> > > To: foreman-dev@googlegroups.com
> >>>>> > > Sent: Thursday, February 6, 2014 4:48:02 PM
> >>>>> > > Subject: Re: [foreman-dev] Updating many-to-many relationships
> >>>>> > >
> >>>>> > > On 01/30/2014 02:31 PM, Bryan Kearney wrote:
> >>>>> > > > On 01/30/2014 08:19 AM, Joseph Magen wrote:
> >>>>> > > >> ----- Original Message -----
> >>>>> > > >>> From: "Bryan Kearney"
> >>>>> > > >>> To: foreman-dev@googlegroups.com
> >>>>> > > >>> Sent: Thursday, January 30, 2014 3:13:37 PM
> >>>>> > > >>> Subject: Re: [foreman-dev] Updating many-to-many relationships
> >>>>> > > >>>
> >>>>> > > >>> On 01/30/2014 02:42 AM, Joseph Magen wrote:
> >>>>> > > >>>> To be specific and atomic, then you need to treat the
> >>>>> > > >>>> many-to-many
> >>>>> > > >>>> relation
> >>>>> > > >>>> as its own resource. This is not the case with our example
> >>>>> > > >>>>
> >>>>> > > >>>> PUT api/v2/operatingsystems/24
> >>>>> > > >>>>
> >>>>> > > >>>> which update all the attributes AND associations for resource
> >>>>> > > >>>> operating
> >>>>> > > >>>> system #24
> >>>>> > > >>>>
> >>>>> > > >>>> The RESTful way to only add or delete an association (similar
> >>>>> > > >>>> to
> >>>>> > > >>>> what we
> >>>>> > > >>>> did for host_classes and hostgroup_classes) is this below:
> >>>>> > > >>>> (Note
> >>>>> > > >>>> that BOTH
> >>>>> > > >>>> the architecture id and operating system id's already exist)
> >>>>> > > >>>>
> >>>>> > > >>>> Create a new association
> >>>>> > > >>>> POST api/v2/operatingsystems/24/architectures_operatingsystems
> >>>>> > > >>>> -d
> >>>>> > > >>>> {'id': 1}
> >>>>> > > >>>>
> >>>>> > > >>>> object created
> >>>>> > > >>>> {
> >>>>> > > >>>> 'id': 555
> >>>>> > > >>>> 'operatingsystem_id': 24
> >>>>> > > >>>> 'architecture_id': 1
> >>>>> > > >>>> }
> >>>>> > > >>>>
> >>>>> > > >>>> Delete an association
> >>>>> > > >>>> DELETE
> >>>>> > > >>>> api/v2/operatingsystems/24/architectures_operatingsystems/555
> >>>>> > > >>>>
> >>>>> > > >>>> This is similar to what Bryan may thought of when he wrote
> >>>>> > > >>>>
> >>>>> > > >>>>> What about a
> >>>>> > > >>>>> PUT api/v2/operatingsystems/24/architectures
> >>>>> > > >>>>
> >>>>> > > >>>> But the issue here is that PUT requires an ID of a resource to
> >>>>> > > >>>> update.
> >>>>> > > >>>
> >>>>> > > >>>
> >>>>> > > >>> yeah... I should have put POST.
> >>>>> > > >>>
> >>>>> > > >>>>
> >>>>> > > >>>> The 'problem' with the atomic restful way is that most
> >>>>> > > >>>> 'simple'
> >>>>> > > >>>> API's don't
> >>>>> > > >>>> expose the database internals such as id #555 on a join table
> >>>>> > > >>>> which
> >>>>> > > >>>> is
> >>>>> > > >>>> meaningless to the user.
> >>>>> > > >>>
> >>>>> > > >>> I would make it architectures. That way the join parrt is
> >>>>> > > >>> hidden
> >>>>> > > >>> a
> >>>>> > > >>> bit.
> >>>>> > > >>
> >>>>> > > >>
> >>>>> > > >> POST api/v2/operatingsystems/24/architectures -d {'id': 1}
> >>>>> > > >>
> >>>>> > > >> This would be confusing, since in RESTful style, a POST on a
> >>>>> > > >> collection (architectures) creates a new architecture.
> >>>>> > > >
> >>>>> > > >
> >>>>> > > > You are correct.. but this for me is when the REST WILL SOLVE ALL
> >>>>> > > > ISSUES argument starts to fail. Haveing a resource which is
> >>>>> > > >
> >>>>> > > > api/v2/operatingsystems_architectures_relationship
> >>>>> > > >
> >>>>> > > > is just nasty in IMHO. I would prefer a POST to
> >>>>> > > > api/v2/operatingsystems/24/architectures which either does a
> >>>>> > > > CREATE
> >>>>> > > > or
> >>>>> > > > FIND based on the presence of hte ID attribute. But, that is just
> >>>>> > > > me
> >>>>> > > > :)
> >>>>> > > >
> >>>>> > > > BTw... I am still waiting for the REST client which
> >>>>> > > > actually
> >>>>> > > > parses the url fragments which REST produces to "follow" the api"
> >>>>> > > >
> >>>>> > > >
> >>>>> > > > -- bk
> >>>>> > > >
> >>>>> > > >
> >>>>> > > I'd suggest something similar to what Bryan came up with
> >>>>> > >
> >>>>> > > PUT api/v2/operatingsystems/24/add_architecture/2
> >>>>> > > PUT api/v2/operatingsystems/24/remove_architecture/2
> >>>>> > >
> >>>>> > > The reason would be that the relation is not a resource but rather
> >>>>> > > an
> >>>>> > > attribute. I'd use PUT as the operation is idempotent and from
> >>>>> > > users
> >>>>> > > perspective it alters the os resource.
> >>>>> > >
> >>>>> > > Makes sense?
> >>>>> > >
> >>>>> > > M
> >>>>> > >
> >>>>> > > --
> >>>>> > > You received this message because you are subscribed to the Google
> >>>>> > > Groups
> >>>>> > > "foreman-dev" group.
> >>>>> > > To unsubscribe from this group and stop receiving emails from it,
> >>>>> > > send
> >>>>> > > an
> >>>>> > > email to foreman-dev+unsubscribe@googlegroups.com.
> >>>>> > > For more options, visit https://groups.google.com/groups/opt_out.
> >>>>> > >
> >>>>> >
> >>>>> > --
> >>>>> > You received this message because you are subscribed to the Google
> >>>>> > Groups
> >>>>> > "foreman-dev" group.
> >>>>> > To unsubscribe from this group and stop receiving emails from it,
> >>>>> > send
> >>>>> > an
> >>>>> > email to foreman-dev+unsubscribe@googlegroups.com.
> >>>>> > For more options, visit https://groups.google.com/groups/opt_out.
> >>>>> >
> >>>>>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups
> >>>>> "foreman-dev" group.
> >>>>> To unsubscribe from this group and stop receiving emails from it, send
> >>>>> an
> >>>>> email to foreman-dev+unsubscribe@googlegroups.com.
> >>>>> For more options, visit https://groups.google.com/groups/opt_out.
> >>>>>
> >>>>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups
> >>>> "foreman-dev" group.
> >>>> To unsubscribe from this group and stop receiving emails from it, send
> >>>> an
> >>>> email to foreman-dev+unsubscribe@googlegroups.com.
> >>>> For more options, visit https://groups.google.com/groups/opt_out.
> >>>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "foreman-dev" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send an
> >>> email to foreman-dev+unsubscribe@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>>
> >>
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
PUT /operatingsystems/24/add_architecture/2
PUT /operatingsystems/24/remove_architecture/2
David
···
----- Original Message -----
> From: "David Davis"
> To: foreman-dev@googlegroups.com
> Sent: Monday, May 19, 2014 9:07:38 AM
> Subject: Re: [foreman-dev] Updating many-to-many relationships
>
> In Katello, we do it two ways. We support the foreman/hammer method:
>
> POST /operatingsystems/:operatingsystem_id {"architecture_ids": [1,2,3]}
> DELETE /operatingsystems/:operatingsystem_id {"architecture_ids": [1,2,3]}
>
> And we have a way to add/remove individual items:
>
> PUT /operatingsystems/24/add_architecture/2
> DELETE /operatingsystems/24/remove_architecture/2
>
> David
>
> ----- Original Message -----
> > From: "Tomas Strachota"
> > To: foreman-dev@googlegroups.com
> > Sent: Monday, May 19, 2014 5:09:19 AM
> > Subject: Re: [foreman-dev] Updating many-to-many relationships
> >
> > On 05/19/2014 09:47 AM, Ivan Necas wrote:
> > >
> > > ----- Original Message -----
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> Reviving an old thread
> > >>>
> > >>> I push a new commit to https://github.com/theforeman/foreman/pull/1068
> > >>> entited
> > >>>
> > >>> fixes #5780 - API v2 - RESTful way to add/remove many-to-many
> > >>> association
> > >>> one at a time rather than passing all id's
> > >>>
> > >>> It is part of the PR to add's nested routes.
> > >>>
> > >>> I only included adding/removing many-to-many relationship between
> > >>> architectures & operating systems. If we all agree, then I'll add the
> > >>> other
> > >>> n:n associations.
> > >>>
> > >>> In short, the RESTful way is this
> > >>>
> > >>> POST
> > >>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
> > >>> DELETE
> > >>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/architecture_operatingsystems
> > >>>
> > >>> However, I changed it slightly to
> > >>>
> > >>> POST
> > >>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/add
> > >>> DELETE
> > >>> /operatingsystems/:operatingsystem_id/architectures/:architecture_id/remove
> > >>
> > >> Wouldn't be the the RESTful way?:
> > >>
> > >> POST /operatingsystems/:operatingsystem_id/architectures {
> > >> "architecture_id":
> > >> 1}
> > >> DELETE
> > >> /operatingsystems/:operatingsystem_id/architectures/:architecture_id
> > >>
> > >> POST and DELETE already should have the meaning of adding/removing the
> > >> resource
> >
> > I know rest purists might argue but I find Ivan's routes more intuitive.
> >
> > Just out of my curiosity, what way is used in katello at the moment?
> > Ideally we should be converging to a consistent route style.
> >
> > Joseph, is there any "api guidelines" document, we could refer to, please?
> >
> > >>
> > >> I might have missed the discussion around that, so somebody might just
> > >> update
> > >> me on the reasons for choosing this path?
> > >>
> > >> Thanks
> > >>
> > >> -- Ivan
> > >>
> > >>>
> > >>> I don't see the advantage of exposing 'architecture_operatingsystems'
> > >>> in
> > >>> the
> > >>> path. Even tough the keywords such as "add, create, delete, remove"
> > >>> usually
> > >>> don't appear in the URL as they are inferred by HTTP VERBS, I think in
> > >>> this
> > >>> case, it's more intuitive than having a meaninglessly join-table name.
> > >
> > > +1 on not exposing the ArchitectureOperatingSystem as a resource.
> >
> > +1 let's not expose them, please.
> >
> > >
> > >>>
> > >>> What are your thoughts?
> > >>>
> > >>> Joseph
> > >>> Red Hat Engineering
> > >>>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Joseph Magen"
> > >>>> To: foreman-dev@googlegroups.com
> > >>>> Sent: Thursday, February 6, 2014 5:06:04 PM
> > >>>> Subject: Re: [foreman-dev] Updating many-to-many relationships
> > >>>>
> > >>>> You can write the docs but wait until the feature is merged in
> > >>>> 'develop'
> > >>>> until you merge the docs in theforeman.org.
> > >>>>
> > >>>> Can you also add this feature issue to redmine.
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Joseph
> > >>>>
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "David Davis"
> > >>>>> To: foreman-dev@googlegroups.com
> > >>>>> Sent: Thursday, February 6, 2014 4:56:49 PM
> > >>>>> Subject: Re: [foreman-dev] Updating many-to-many relationships
> > >>>>>
> > >>>>> Should I add this to the documentation?
> > >>>>>
> > >>>>> David
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>> > From: "Joseph Magen"
> > >>>>> > To: foreman-dev@googlegroups.com
> > >>>>> > Sent: Thursday, February 6, 2014 9:55:00 AM
> > >>>>> > Subject: Re: [foreman-dev] Updating many-to-many relationships
> > >>>>> >
> > >>>>> > OK, I will do this
> > >>>>> >
> > >>>>> > > PUT api/v2/operatingsystems/24/add_architecture/2
> > >>>>> > > PUT api/v2/operatingsystems/24/remove_architecture/2
> > >>>>> >
> > >>>>> >
> > >>>>> >
> > >>>>> > ----- Original Message -----
> > >>>>> > > From: "Martin Bačovský"
> > >>>>> > > To: foreman-dev@googlegroups.com
> > >>>>> > > Sent: Thursday, February 6, 2014 4:48:02 PM
> > >>>>> > > Subject: Re: [foreman-dev] Updating many-to-many relationships
> > >>>>> > >
> > >>>>> > > On 01/30/2014 02:31 PM, Bryan Kearney wrote:
> > >>>>> > > > On 01/30/2014 08:19 AM, Joseph Magen wrote:
> > >>>>> > > >> ----- Original Message -----
> > >>>>> > > >>> From: "Bryan Kearney"
> > >>>>> > > >>> To: foreman-dev@googlegroups.com
> > >>>>> > > >>> Sent: Thursday, January 30, 2014 3:13:37 PM
> > >>>>> > > >>> Subject: Re: [foreman-dev] Updating many-to-many
> > >>>>> > > >>> relationships
> > >>>>> > > >>>
> > >>>>> > > >>> On 01/30/2014 02:42 AM, Joseph Magen wrote:
> > >>>>> > > >>>> To be specific and atomic, then you need to treat the
> > >>>>> > > >>>> many-to-many
> > >>>>> > > >>>> relation
> > >>>>> > > >>>> as its own resource. This is not the case with our example
> > >>>>> > > >>>>
> > >>>>> > > >>>> PUT api/v2/operatingsystems/24
> > >>>>> > > >>>>
> > >>>>> > > >>>> which update all the attributes AND associations for
> > >>>>> > > >>>> resource
> > >>>>> > > >>>> operating
> > >>>>> > > >>>> system #24
> > >>>>> > > >>>>
> > >>>>> > > >>>> The RESTful way to only add or delete an association
> > >>>>> > > >>>> (similar
> > >>>>> > > >>>> to
> > >>>>> > > >>>> what we
> > >>>>> > > >>>> did for host_classes and hostgroup_classes) is this below:
> > >>>>> > > >>>> (Note
> > >>>>> > > >>>> that BOTH
> > >>>>> > > >>>> the architecture id and operating system id's already exist)
> > >>>>> > > >>>>
> > >>>>> > > >>>> Create a new association
> > >>>>> > > >>>> POST
> > >>>>> > > >>>> api/v2/operatingsystems/24/architectures_operatingsystems
> > >>>>> > > >>>> -d
> > >>>>> > > >>>> {'id': 1}
> > >>>>> > > >>>>
> > >>>>> > > >>>> object created
> > >>>>> > > >>>> {
> > >>>>> > > >>>> 'id': 555
> > >>>>> > > >>>> 'operatingsystem_id': 24
> > >>>>> > > >>>> 'architecture_id': 1
> > >>>>> > > >>>> }
> > >>>>> > > >>>>
> > >>>>> > > >>>> Delete an association
> > >>>>> > > >>>> DELETE
> > >>>>> > > >>>> api/v2/operatingsystems/24/architectures_operatingsystems/555
> > >>>>> > > >>>>
> > >>>>> > > >>>> This is similar to what Bryan may thought of when he wrote
> > >>>>> > > >>>>
> > >>>>> > > >>>>> What about a
> > >>>>> > > >>>>> PUT api/v2/operatingsystems/24/architectures
> > >>>>> > > >>>>
> > >>>>> > > >>>> But the issue here is that PUT requires an ID of a resource
> > >>>>> > > >>>> to
> > >>>>> > > >>>> update.
> > >>>>> > > >>>
> > >>>>> > > >>>
> > >>>>> > > >>> yeah... I should have put POST.
> > >>>>> > > >>>
> > >>>>> > > >>>>
> > >>>>> > > >>>> The 'problem' with the atomic restful way is that most
> > >>>>> > > >>>> 'simple'
> > >>>>> > > >>>> API's don't
> > >>>>> > > >>>> expose the database internals such as id #555 on a join
> > >>>>> > > >>>> table
> > >>>>> > > >>>> which
> > >>>>> > > >>>> is
> > >>>>> > > >>>> meaningless to the user.
> > >>>>> > > >>>
> > >>>>> > > >>> I would make it architectures. That way the join parrt is
> > >>>>> > > >>> hidden
> > >>>>> > > >>> a
> > >>>>> > > >>> bit.
> > >>>>> > > >>
> > >>>>> > > >>
> > >>>>> > > >> POST api/v2/operatingsystems/24/architectures -d {'id': 1}
> > >>>>> > > >>
> > >>>>> > > >> This would be confusing, since in RESTful style, a POST on a
> > >>>>> > > >> collection (architectures) creates a new architecture.
> > >>>>> > > >
> > >>>>> > > >
> > >>>>> > > > You are correct.. but this for me is when the REST WILL SOLVE
> > >>>>> > > > ALL
> > >>>>> > > > ISSUES argument starts to fail. Haveing a resource which is
> > >>>>> > > >
> > >>>>> > > > api/v2/operatingsystems_architectures_relationship
> > >>>>> > > >
> > >>>>> > > > is just nasty in IMHO. I would prefer a POST to
> > >>>>> > > > api/v2/operatingsystems/24/architectures which either does a
> > >>>>> > > > CREATE
> > >>>>> > > > or
> > >>>>> > > > FIND based on the presence of hte ID attribute. But, that is
> > >>>>> > > > just
> > >>>>> > > > me
> > >>>>> > > > :)
> > >>>>> > > >
> > >>>>> > > > BTw... I am still waiting for the REST client which
> > >>>>> > > > actually
> > >>>>> > > > parses the url fragments which REST produces to "follow" the
> > >>>>> > > > api"
> > >>>>> > > >
> > >>>>> > > >
> > >>>>> > > > -- bk
> > >>>>> > > >
> > >>>>> > > >
> > >>>>> > > I'd suggest something similar to what Bryan came up with
> > >>>>> > >
> > >>>>> > > PUT api/v2/operatingsystems/24/add_architecture/2
> > >>>>> > > PUT api/v2/operatingsystems/24/remove_architecture/2
> > >>>>> > >
> > >>>>> > > The reason would be that the relation is not a resource but
> > >>>>> > > rather
> > >>>>> > > an
> > >>>>> > > attribute. I'd use PUT as the operation is idempotent and from
> > >>>>> > > users
> > >>>>> > > perspective it alters the os resource.
> > >>>>> > >
> > >>>>> > > Makes sense?
> > >>>>> > >
> > >>>>> > > M
> > >>>>> > >
> > >>>>> > > --
> > >>>>> > > You received this message because you are subscribed to the
> > >>>>> > > Google
> > >>>>> > > Groups
> > >>>>> > > "foreman-dev" group.
> > >>>>> > > To unsubscribe from this group and stop receiving emails from it,
> > >>>>> > > send
> > >>>>> > > an
> > >>>>> > > email to foreman-dev+unsubscribe@googlegroups.com.
> > >>>>> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >>>>> > >
> > >>>>> >
> > >>>>> > --
> > >>>>> > You received this message because you are subscribed to the Google
> > >>>>> > Groups
> > >>>>> > "foreman-dev" group.
> > >>>>> > To unsubscribe from this group and stop receiving emails from it,
> > >>>>> > send
> > >>>>> > an
> > >>>>> > email to foreman-dev+unsubscribe@googlegroups.com.
> > >>>>> > For more options, visit https://groups.google.com/groups/opt_out.
> > >>>>> >
> > >>>>>
> > >>>>> --
> > >>>>> You received this message because you are subscribed to the Google
> > >>>>> Groups
> > >>>>> "foreman-dev" group.
> > >>>>> To unsubscribe from this group and stop receiving emails from it,
> > >>>>> send
> > >>>>> an
> > >>>>> email to foreman-dev+unsubscribe@googlegroups.com.
> > >>>>> For more options, visit https://groups.google.com/groups/opt_out.
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> You received this message because you are subscribed to the Google
> > >>>> Groups
> > >>>> "foreman-dev" group.
> > >>>> To unsubscribe from this group and stop receiving emails from it, send
> > >>>> an
> > >>>> email to foreman-dev+unsubscribe@googlegroups.com.
> > >>>> For more options, visit https://groups.google.com/groups/opt_out.
> > >>>>
> > >>>
> > >>> --
> > >>> You received this message because you are subscribed to the Google
> > >>> Groups
> > >>> "foreman-dev" group.
> > >>> To unsubscribe from this group and stop receiving emails from it, send
> > >>> an
> > >>> email to foreman-dev+unsubscribe@googlegroups.com.
> > >>> For more options, visit https://groups.google.com/d/optout.
> > >>>
> > >>
> > >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
