> From: "David Davis" <ddavis1@gmail.com>
> To: jmagen@redhat.com
> Sent: Wednesday, November 20, 2013 2:07:53 PM
> Subject: Re: [foreman-dev] V2 API questions
>
>
>
> > > I'm working on a V2 controller and had some questions. Given the
> > inconsistencies of the V1 code, I was hoping we could maybe standardize the
> > code design for our v2 controllers/views/etc (at least in Katello). I'm not
> > sure if any of this applies to Foreman unless we want to standardize across
> > both apps. Here are some of my questions:
> > >
> > > 1. Does /systems/:id/subscriptions route to systems#subscriptions or
> > subscriptions#index? We seem to have nested routes that differ on this in
> > V2 (e.g. systems#subscriptions vs system_group#systems).
> >
> > What do you mean route? I would assume that /systems/:id/subscriptions
> > is equivilant to /subscriptions?system_id=:id
> >
>
> In Rails, each route maps it to a set of controller + action (ie
> controller#action). I'm asking which controller and action
> /systems/:id/subscriptions routes to. Like you, I would assume that
> /systems/:id/subscriptions would route to the same place as /subscriptions
> (subscriptions#index) but in Katello, this is usually not the case–we have
> routes like /organizations/:id/subscriptions =>
> subscriptions#organization_index, /system_groups/:id/systems =>
> system_groups#systems, etc.
#1) If routes.rb is setup below in the RESTful way, then it routes to subscriptions#index
resources :systems do
resources :subscriptions
end
#2) If routes.rb is set up like this, then it routes to systems#subscriptions
resources :systems do
get :subscriptions, :on => :member
end
Looking at katello routes.rb, it is indeed #2
resources :systems do
member do
get :edit
get :subscriptions
post :update_subscriptions
get :products
get :more_products
get :facts
get :system_groups
put :add_system_groups
put :remove_system_groups
get :custom_info
get :releases
end
Because the code is the #2 way and not RESTful resources, it will be more difficult to make the API conform to a RESTful. The question is whether the Katello team wants to re-factor routes.rb and apoi controllers or stay "as is" and the api rabl views will be more complex.
···
----- Original Message -----
> On Tuesday, November 19, 2013 7:30:56 PM UTC-5, bk wrote:
> > On 11/19/2013 05:40 PM, David Davis wrote:
- Should we maybe turn on wrap_params instead of calling
params.slice(…) and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
I would assume we eventually do all nested…
+1
– bk
On Wednesday, November 20, 2013 2:15:53 AM UTC-5, Joseph Magen wrote:
----- Original Message -----
From: “David Davis” <david...@redhat.com <javascript:>>
To: “foreman-dev” <forem...@googlegroups.com <javascript:>>
Sent: Wednesday, November 20, 2013 12:40:24 AM
Subject: [foreman-dev] V2 API questions
I’m working on a V2 controller and had some questions. Given the
inconsistencies of the V1 code, I was hoping we could maybe standardize
the
code design for our v2 controllers/views/etc (at least in Katello). I’m
not
sure if any of this applies to Foreman unless we want to standardize
across
both apps. Here are some of my questions:
- Does /systems/:id/subscriptions route to systems#subscriptions or
subscriptions#index? We seem to have nested routes that differ on this
in V2
(e.g. systems#subscriptions vs system_group#systems).
Both are possible depending on how routes.rb is defined, but the RESTful
way is /systems/:id/subscriptions => subscriptions#index with
params[‘system_id’]=:id. Note the #index action needs to do the filtering.
It’s not automatic.
So I know both are possible and I tend to agree with the RESTful way.
- Should we maybe turn on wrap_params instead of calling
params.slice(…)
and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
- It seems like the search code is duplicated in a lot of places in V2.
Should we try to DRY this up?
Please give example. In foreman, you will see as an example
Puppetclass.search_for(*search_options)
where def search_options is defined in base_controller.rb
This one I am not too concerned about right now but here are some examples:
katello/app/controllers/api/v2/systems_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/products_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/repositories_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
I’m wondering if we should address these as they come up? Should we
maybe try
to include their resolutions in the V2 developer documentation?
Thanks.
David
–
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
Also, I’m all up for using wrap_parameters and (eventually) switching to
update_attributes(params[:model]) unless anyone else is opposed?
>
> > From: "David Davis" <dda…@gmail.com <javascript:>>
> > To: jma...@redhat.com <javascript:>
> > Sent: Wednesday, November 20, 2013 2:07:53 PM
> > Subject: Re: [foreman-dev] V2 API questions
> >
> >
> >
> > > > I'm working on a V2 controller and had some questions. Given the
> > > inconsistencies of the V1 code, I was hoping we could maybe
> standardize the
> > > code design for our v2 controllers/views/etc (at least in Katello).
> I'm not
> > > sure if any of this applies to Foreman unless we want to standardize
> across
> > > both apps. Here are some of my questions:
> > > >
> > > > 1. Does /systems/:id/subscriptions route to systems#subscriptions or
> > > subscriptions#index? We seem to have nested routes that differ on this
> in
> > > V2 (e.g. systems#subscriptions vs system_group#systems).
> > >
> > > What do you mean route? I would assume that /systems/:id/subscriptions
> > > is equivilant to /subscriptions?system_id=:id
> > >
> >
> > In Rails, each route maps it to a set of controller + action (ie
> > controller#action). I'm asking which controller and action
> > /systems/:id/subscriptions routes to. Like you, I would assume that
> > /systems/:id/subscriptions would route to the same place as
> /subscriptions
> > (subscriptions#index) but in Katello, this is usually not the case–we
> have
> > routes like /organizations/:id/subscriptions =>
> > subscriptions#organization_index, /system_groups/:id/systems =>
> > system_groups#systems, etc.
>
> #1) If routes.rb is setup below in the RESTful way, then it routes to
> subscriptions#index
>
> resources :systems do
> resources :subscriptions
> end
>
> #2) If routes.rb is set up like this, then it routes to
> systems#subscriptions
>
> resources :systems do
> get :subscriptions, :on => :member
> end
>
> Looking at katello routes.rb, it is indeed #2
>
> resources :systems do
> member do
> get :edit
> get :subscriptions
> post :update_subscriptions
> get :products
> get :more_products
> get :facts
> get :system_groups
> put :add_system_groups
> put :remove_system_groups
> get :custom_info
> get :releases
> end
>
> Because the code is the #2 way and not RESTful resources, it will be more
> difficult to make the API conform to a RESTful. The question is whether
> the Katello team wants to re-factor routes.rb and apoi controllers or stay
> "as is" and the api rabl views will be more complex.
>
>
The stuff in our routes file is going away (eventually) as our new UI which
just hits our V2 API. If you look in our V2 API routes file, you'll see
(#1):
api_resources :systems do
api_resources :subscriptions
end
That said, if you look in our old API V1 file, you'll see
···
On Wednesday, November 20, 2013 7:30:58 AM UTC-5, Joseph Magen wrote:
> ----- Original Message -----
> > On Tuesday, November 19, 2013 7:30:56 PM UTC-5, bk wrote:
> > > On 11/19/2013 05:40 PM, David Davis wrote:
- Should we maybe turn on wrap_params instead of calling
params.slice(…) and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
I would assume we eventually do all nested…
+1
– bk
On Wednesday, November 20, 2013 2:15:53 AM UTC-5, Joseph Magen wrote:
----- Original Message -----
From: “David Davis” <david...@redhat.com <javascript:>>
To: “foreman-dev” <forem...@googlegroups.com <javascript:>>
Sent: Wednesday, November 20, 2013 12:40:24 AM
Subject: [foreman-dev] V2 API questions
I’m working on a V2 controller and had some questions. Given the
inconsistencies of the V1 code, I was hoping we could maybe
standardize
the
code design for our v2 controllers/views/etc (at least in Katello).
I’m
not
sure if any of this applies to Foreman unless we want to standardize
across
both apps. Here are some of my questions:
- Does /systems/:id/subscriptions route to systems#subscriptions or
subscriptions#index? We seem to have nested routes that differ on
this
in V2
(e.g. systems#subscriptions vs system_group#systems).
Both are possible depending on how routes.rb is defined, but the
RESTful
way is /systems/:id/subscriptions => subscriptions#index with
params[‘system_id’]=:id. Note the #index action needs to do the
filtering.
It’s not automatic.
So I know both are possible and I tend to agree with the RESTful way.
- Should we maybe turn on wrap_params instead of calling
params.slice(…)
and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
- It seems like the search code is duplicated in a lot of places in
V2.
Should we try to DRY this up?
Please give example. In foreman, you will see as an example
Puppetclass.search_for(*search_options)
where def search_options is defined in base_controller.rb
This one I am not too concerned about right now but here are some
examples:
katello/app/controllers/api/v2/systems_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/products_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/repositories_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
I’m wondering if we should address these as they come up? Should we
maybe try
to include their resolutions in the V2 developer documentation?
Thanks.
David
–
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
Also, I’m all up for using wrap_parameters and (eventually) switching to
update_attributes(params[:model]) unless anyone else is opposed?
> From: "David Davis" <ddavis1@gmail.com>
> To: foreman-dev@googlegroups.com
> Cc: "David Davis" <ddavis1@gmail.com>
> Sent: Wednesday, November 20, 2013 2:40:01 PM
> Subject: Re: [foreman-dev] V2 API questions
>
>
>
> >
> > > From: "David Davis" <dda…@gmail.com <javascript:>>
> > > To: jma...@redhat.com <javascript:>
> > > Sent: Wednesday, November 20, 2013 2:07:53 PM
> > > Subject: Re: [foreman-dev] V2 API questions
> > >
> > >
> > >
> > > > > I'm working on a V2 controller and had some questions. Given the
> > > > inconsistencies of the V1 code, I was hoping we could maybe
> > standardize the
> > > > code design for our v2 controllers/views/etc (at least in Katello).
> > I'm not
> > > > sure if any of this applies to Foreman unless we want to standardize
> > across
> > > > both apps. Here are some of my questions:
> > > > >
> > > > > 1. Does /systems/:id/subscriptions route to systems#subscriptions or
> > > > subscriptions#index? We seem to have nested routes that differ on this
> > in
> > > > V2 (e.g. systems#subscriptions vs system_group#systems).
> > > >
> > > > What do you mean route? I would assume that /systems/:id/subscriptions
> > > > is equivilant to /subscriptions?system_id=:id
> > > >
> > >
> > > In Rails, each route maps it to a set of controller + action (ie
> > > controller#action). I'm asking which controller and action
> > > /systems/:id/subscriptions routes to. Like you, I would assume that
> > > /systems/:id/subscriptions would route to the same place as
> > /subscriptions
> > > (subscriptions#index) but in Katello, this is usually not the case–we
> > have
> > > routes like /organizations/:id/subscriptions =>
> > > subscriptions#organization_index, /system_groups/:id/systems =>
> > > system_groups#systems, etc.
> >
> > #1) If routes.rb is setup below in the RESTful way, then it routes to
> > subscriptions#index
> >
> > resources :systems do
> > resources :subscriptions
> > end
> >
> > #2) If routes.rb is set up like this, then it routes to
> > systems#subscriptions
> >
> > resources :systems do
> > get :subscriptions, :on => :member
> > end
> >
> > Looking at katello routes.rb, it is indeed #2
> >
> > resources :systems do
> > member do
> > get :edit
> > get :subscriptions
> > post :update_subscriptions
> > get :products
> > get :more_products
> > get :facts
> > get :system_groups
> > put :add_system_groups
> > put :remove_system_groups
> > get :custom_info
> > get :releases
> > end
> >
> > Because the code is the #2 way and not RESTful resources, it will be more
> > difficult to make the API conform to a RESTful. The question is whether
> > the Katello team wants to re-factor routes.rb and apoi controllers or stay
> > "as is" and the api rabl views will be more complex.
> >
> >
> The stuff in our routes file is going away (eventually) as our new UI which
> just hits our V2 API. If you look in our V2 API routes file, you'll see
> (#1):
>
> api_resources :systems do
> api_resources :subscriptions
> end
Your right. I should have looked at v2.rb. It's in the RESTful resources style.
···
----- Original Message -----
> On Wednesday, November 20, 2013 7:30:58 AM UTC-5, Joseph Magen wrote:
> > ----- Original Message -----
> > > On Tuesday, November 19, 2013 7:30:56 PM UTC-5, bk wrote:
> > > > On 11/19/2013 05:40 PM, David Davis wrote:
That said, if you look in our old API V1 file, you’ll see
- Should we maybe turn on wrap_params instead of calling
params.slice(…) and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
I would assume we eventually do all nested…
+1
– bk
On Wednesday, November 20, 2013 2:15:53 AM UTC-5, Joseph Magen wrote:
----- Original Message -----
From: “David Davis” <david...@redhat.com <javascript:>>
To: “foreman-dev” <forem...@googlegroups.com <javascript:>>
Sent: Wednesday, November 20, 2013 12:40:24 AM
Subject: [foreman-dev] V2 API questions
I’m working on a V2 controller and had some questions. Given the
inconsistencies of the V1 code, I was hoping we could maybe
standardize
the
code design for our v2 controllers/views/etc (at least in Katello).
I’m
not
sure if any of this applies to Foreman unless we want to standardize
across
both apps. Here are some of my questions:
- Does /systems/:id/subscriptions route to systems#subscriptions or
subscriptions#index? We seem to have nested routes that differ on
this
in V2
(e.g. systems#subscriptions vs system_group#systems).
Both are possible depending on how routes.rb is defined, but the
RESTful
way is /systems/:id/subscriptions => subscriptions#index with
params[‘system_id’]=:id. Note the #index action needs to do the
filtering.
It’s not automatic.
So I know both are possible and I tend to agree with the RESTful way.
- Should we maybe turn on wrap_params instead of calling
params.slice(…)
and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
- It seems like the search code is duplicated in a lot of places in
V2.
Should we try to DRY this up?
Please give example. In foreman, you will see as an example
Puppetclass.search_for(*search_options)
where def search_options is defined in base_controller.rb
This one I am not too concerned about right now but here are some
examples:
katello/app/controllers/api/v2/systems_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/products_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/repositories_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
I’m wondering if we should address these as they come up? Should we
maybe try
to include their resolutions in the V2 developer documentation?
Thanks.
David
–
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
Also, I’m all up for using wrap_parameters and (eventually) switching to
update_attributes(params[:model]) unless anyone else is opposed?
–
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.
We also have the un-restful style too though:
api_resources :system_groups do
member do
get :systems
end
end
We even have some other patterns too. Here's an example for
organizations/:id/subscriptions:
api_resources :subscriptions do
collection do
get :index, :action => :organization_index
end
end
This is why I want to standardize it.
David
···
On Wed, Nov 20, 2013 at 8:17 AM, Joseph Magen wrote:
----- Original Message -----
From: “David Davis” ddavis1@gmail.com
To: foreman-dev@googlegroups.com
Cc: “David Davis” ddavis1@gmail.com
Sent: Wednesday, November 20, 2013 2:40:01 PM
Subject: Re: [foreman-dev] V2 API questions
On Wednesday, November 20, 2013 7:30:58 AM UTC-5, Joseph Magen wrote:
----- Original Message -----
From: “David Davis” <dda...@gmail.com <javascript:>>
To: jma...@redhat.com <javascript:>
Sent: Wednesday, November 20, 2013 2:07:53 PM
Subject: Re: [foreman-dev] V2 API questions
On Tuesday, November 19, 2013 7:30:56 PM UTC-5, bk wrote:
On 11/19/2013 05:40 PM, David Davis wrote:
I’m working on a V2 controller and had some questions. Given the
inconsistencies of the V1 code, I was hoping we could maybe
standardize the
code design for our v2 controllers/views/etc (at least in Katello).
I’m not
sure if any of this applies to Foreman unless we want to
standardize
across
both apps. Here are some of my questions:
- Does /systems/:id/subscriptions route to
systems#subscriptions or
subscriptions#index? We seem to have nested routes that differ on
this
in
V2 (e.g. systems#subscriptions vs system_group#systems).
What do you mean route? I would assume that
/systems/:id/subscriptions
is equivilant to /subscriptions?system_id=:id
In Rails, each route maps it to a set of controller + action (ie
controller#action). I’m asking which controller and action
/systems/:id/subscriptions routes to. Like you, I would assume that
/systems/:id/subscriptions would route to the same place as
/subscriptions
(subscriptions#index) but in Katello, this is usually not the
case–we
have
routes like /organizations/:id/subscriptions =>
subscriptions#organization_index, /system_groups/:id/systems =>
system_groups#systems, etc.
#1) If routes.rb is setup below in the RESTful way, then it routes to
subscriptions#index
resources :systems do
resources :subscriptions
end
#2) If routes.rb is set up like this, then it routes to
systems#subscriptions
resources :systems do
get :subscriptions, :on => :member
end
Looking at katello routes.rb, it is indeed #2
resources :systems do
member do
get :edit
get :subscriptions
post :update_subscriptions
get :products
get :more_products
get :facts
get :system_groups
put :add_system_groups
put :remove_system_groups
get :custom_info
get :releases
end
Because the code is the #2 way and not RESTful resources, it will be
more
difficult to make the API conform to a RESTful. The question is
whether
the Katello team wants to re-factor routes.rb and apoi controllers or
stay
“as is” and the api rabl views will be more complex.
The stuff in our routes file is going away (eventually) as our new UI
which
just hits our V2 API. If you look in our V2 API routes file, you’ll see
(#1):
api_resources :systems do
api_resources :subscriptions
end
Your right. I should have looked at v2.rb. It’s in the RESTful resources
style.
That said, if you look in our old API V1 file, you’ll see
- Should we maybe turn on wrap_params instead of calling
params.slice(…) and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
I would assume we eventually do all nested…
+1
– bk
On Wednesday, November 20, 2013 2:15:53 AM UTC-5, Joseph Magen wrote:
----- Original Message -----
From: “David Davis” <david...@redhat.com <javascript:>>
To: “foreman-dev” <forem...@googlegroups.com <javascript:>>
Sent: Wednesday, November 20, 2013 12:40:24 AM
Subject: [foreman-dev] V2 API questions
I’m working on a V2 controller and had some questions. Given the
inconsistencies of the V1 code, I was hoping we could maybe
standardize
the
code design for our v2 controllers/views/etc (at least in
Katello).
I’m
not
sure if any of this applies to Foreman unless we want to
standardize
across
both apps. Here are some of my questions:
- Does /systems/:id/subscriptions route to
systems#subscriptions or
subscriptions#index? We seem to have nested routes that differ on
this
in V2
(e.g. systems#subscriptions vs system_group#systems).
Both are possible depending on how routes.rb is defined, but the
RESTful
way is /systems/:id/subscriptions => subscriptions#index with
params[‘system_id’]=:id. Note the #index action needs to do the
filtering.
It’s not automatic.
So I know both are possible and I tend to agree with the RESTful way.
- Should we maybe turn on wrap_params instead of calling
params.slice(…)
and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
- It seems like the search code is duplicated in a lot of
places in
V2.
Should we try to DRY this up?
Please give example. In foreman, you will see as an example
Puppetclass.search_for(*search_options)
where def search_options is defined in base_controller.rb
This one I am not too concerned about right now but here are some
examples:
katello/app/controllers/api/v2/systems_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/products_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/repositories_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
I’m wondering if we should address these as they come up? Should
we
maybe try
to include their resolutions in the V2 developer documentation?
Thanks.
David
–
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out
.
Also, I’m all up for using wrap_parameters and (eventually)
switching to
update_attributes(params[:model]) unless anyone else is opposed?
–
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.
> From: "David Davis" <ddavis1@gmail.com>
> To: "Joseph Magen" <jmagen@redhat.com>
> Cc: foreman-dev@googlegroups.com
> Sent: Wednesday, November 20, 2013 3:20:33 PM
> Subject: Re: [foreman-dev] V2 API questions
>
> We also have the un-restful style too though:
>
> api_resources :system_groups do
> member do
> get :systems
> end
> end
the above becomes:
api_resources :system_groups do
api_resources :systems
end
>
> We even have some other patterns too. Here's an example for
> organizations/:id/subscriptions:
>
> api_resources :subscriptions do
> collection do
> get :index, :action => :organization_index
> end
> end
this is an interesting one. What is the path? It seems /subscriptions goes to a method called :organization_index in the subscriptions_controller ?? since /index in get :index does not need to be written.
···
----- Original Message -----
This is why I want to standardize it.
David
On Wed, Nov 20, 2013 at 8:17 AM, Joseph Magen jmagen@redhat.com wrote:
----- Original Message -----
From: “David Davis” ddavis1@gmail.com
To: foreman-dev@googlegroups.com
Cc: “David Davis” ddavis1@gmail.com
Sent: Wednesday, November 20, 2013 2:40:01 PM
Subject: Re: [foreman-dev] V2 API questions
On Wednesday, November 20, 2013 7:30:58 AM UTC-5, Joseph Magen wrote:
----- Original Message -----
From: “David Davis” <dda...@gmail.com <javascript:>>
To: jma...@redhat.com <javascript:>
Sent: Wednesday, November 20, 2013 2:07:53 PM
Subject: Re: [foreman-dev] V2 API questions
On Tuesday, November 19, 2013 7:30:56 PM UTC-5, bk wrote:
On 11/19/2013 05:40 PM, David Davis wrote:
I’m working on a V2 controller and had some questions. Given the
inconsistencies of the V1 code, I was hoping we could maybe
standardize the
code design for our v2 controllers/views/etc (at least in Katello).
I’m not
sure if any of this applies to Foreman unless we want to
standardize
across
both apps. Here are some of my questions:
- Does /systems/:id/subscriptions route to
systems#subscriptions or
subscriptions#index? We seem to have nested routes that differ on
this
in
V2 (e.g. systems#subscriptions vs system_group#systems).
What do you mean route? I would assume that
/systems/:id/subscriptions
is equivilant to /subscriptions?system_id=:id
In Rails, each route maps it to a set of controller + action (ie
controller#action). I’m asking which controller and action
/systems/:id/subscriptions routes to. Like you, I would assume that
/systems/:id/subscriptions would route to the same place as
/subscriptions
(subscriptions#index) but in Katello, this is usually not the
case–we
have
routes like /organizations/:id/subscriptions =>
subscriptions#organization_index, /system_groups/:id/systems =>
system_groups#systems, etc.
#1) If routes.rb is setup below in the RESTful way, then it routes to
subscriptions#index
resources :systems do
resources :subscriptions
end
#2) If routes.rb is set up like this, then it routes to
systems#subscriptions
resources :systems do
get :subscriptions, :on => :member
end
Looking at katello routes.rb, it is indeed #2
resources :systems do
member do
get :edit
get :subscriptions
post :update_subscriptions
get :products
get :more_products
get :facts
get :system_groups
put :add_system_groups
put :remove_system_groups
get :custom_info
get :releases
end
Because the code is the #2 way and not RESTful resources, it will be
more
difficult to make the API conform to a RESTful. The question is
whether
the Katello team wants to re-factor routes.rb and apoi controllers or
stay
“as is” and the api rabl views will be more complex.
The stuff in our routes file is going away (eventually) as our new UI
which
just hits our V2 API. If you look in our V2 API routes file, you’ll see
(#1):
api_resources :systems do
api_resources :subscriptions
end
Your right. I should have looked at v2.rb. It’s in the RESTful resources
style.
That said, if you look in our old API V1 file, you’ll see
- Should we maybe turn on wrap_params instead of calling
params.slice(…) and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
I would assume we eventually do all nested…
+1
– bk
On Wednesday, November 20, 2013 2:15:53 AM UTC-5, Joseph Magen wrote:
----- Original Message -----
From: “David Davis” <david...@redhat.com <javascript:>>
To: “foreman-dev” <forem...@googlegroups.com <javascript:>>
Sent: Wednesday, November 20, 2013 12:40:24 AM
Subject: [foreman-dev] V2 API questions
I’m working on a V2 controller and had some questions. Given the
inconsistencies of the V1 code, I was hoping we could maybe
standardize
the
code design for our v2 controllers/views/etc (at least in
Katello).
I’m
not
sure if any of this applies to Foreman unless we want to
standardize
across
both apps. Here are some of my questions:
- Does /systems/:id/subscriptions route to
systems#subscriptions or
subscriptions#index? We seem to have nested routes that differ on
this
in V2
(e.g. systems#subscriptions vs system_group#systems).
Both are possible depending on how routes.rb is defined, but the
RESTful
way is /systems/:id/subscriptions => subscriptions#index with
params[‘system_id’]=:id. Note the #index action needs to do the
filtering.
It’s not automatic.
So I know both are possible and I tend to agree with the RESTful way.
- Should we maybe turn on wrap_params instead of calling
params.slice(…)
and params.except(…) everywhere?
- When should we nest associations? I saw that we have like
system_groups/:id/systems but that we were not allowing
organizations/:id/system_groups. Where do we draw the line?
- It seems like the search code is duplicated in a lot of
places in
V2.
Should we try to DRY this up?
Please give example. In foreman, you will see as an example
Puppetclass.search_for(*search_options)
where def search_options is defined in base_controller.rb
This one I am not too concerned about right now but here are some
examples:
katello/app/controllers/api/v2/systems_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/products_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
katello/app/controllers/api/v2/repositories_controller.rb at 691a50a5ca5e006e55f3c9a28643f3eac820db95 · Katello/katello · GitHub
I’m wondering if we should address these as they come up? Should
we
maybe try
to include their resolutions in the V2 developer documentation?
Thanks.
David
–
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out
.
Also, I’m all up for using wrap_parameters and (eventually)
switching to
update_attributes(params[:model]) unless anyone else is opposed?
–
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.
