V2 API questions

> 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:
  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…) and params.except(…) everywhere?
  2. 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:

  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).

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.

  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…)
    and params.except(…) everywhere?
  2. 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?
  3. 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:

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/systems_controller.rb#L96-L122
https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/products_controller.rb#L52-L71
https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/repositories_controller.rb#L63-L87

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:
  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…) and params.except(…) everywhere?
  2. 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:

  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).

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.

  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…)
    and params.except(…) everywhere?
  2. 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?
  3. 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:

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/systems_controller.rb#L96-L122

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/products_controller.rb#L52-L71

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/repositories_controller.rb#L63-L87

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

  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…) and params.except(…) everywhere?
  2. 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:

  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).

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.

  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…)
    and params.except(…) everywhere?
  2. 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?
  3. 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:

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/systems_controller.rb#L96-L122

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/products_controller.rb#L52-L71

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/repositories_controller.rb#L63-L87

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:

  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.

That said, if you look in our old API V1 file, you’ll see

  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…) and params.except(…) everywhere?
  2. 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:

  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).

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.

  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…)
    and params.except(…) everywhere?
  2. 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?
  3. 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:

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/systems_controller.rb#L96-L122

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/products_controller.rb#L52-L71

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/repositories_controller.rb#L63-L87

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:

  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.

That said, if you look in our old API V1 file, you’ll see

  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…) and params.except(…) everywhere?
  2. 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:

  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).

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.

  1. Should we maybe turn on wrap_params instead of calling
    params.slice(…)
    and params.except(…) everywhere?
  2. 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?
  3. 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:

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/systems_controller.rb#L96-L122

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/products_controller.rb#L52-L71

https://github.com/Katello/katello/blob/691a50a5ca5e006e55f3c9a28643f3eac820db95/app/controllers/api/v2/repositories_controller.rb#L63-L87

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.