Api v2 - displaying associations in json responses

Development
1

> Tomas,
>
> Both are fine. It's a matter of preference. I don't know of a standard "best
> practice" to display belongs_to associations in the root node or in a child
> node.
>
> I think easier in a collection of objects (ex. hosts) to show the _name
> fields in the root node like we're doing it, but I understand your point.
>
> {
> "name": "fdev2.examplecom",
> "id": 394,
> "environment_id": 1,
> "environment_name": "production",
>
> I'm open to either way. Maybe the best option is to have an option to show
> belongs_to in the root or as child nodes.

I'm not a huge fan of options in terms of format of the API response, as it increases
the complexity and might cause unnecessary confusion. We could get the option there later
once it's clear we need the option at all and the sub-nodes approach is not enough.

– Ivan

··· ----- Original Message -----

Joseph

----- Original Message -----

From: “Tomas Strachota” tstrachota@redhat.com
To: foreman-dev@googlegroups.com
Sent: Tuesday, April 22, 2014 6:31:47 PM
Subject: [foreman-dev] api v2 - displaying associations in json responses

Hello,
I came across an api v2 feature that started to seem a bit inconsistent
to me.

In the api index and show responses we handle has_many and belongs_to
relationships differently. Using rabl terminology, has_many associations
are modeled as child nodes with very limited fields (defined in
base.json.rabl) while belongs_to associations are modeled as first-level
attributes.

Example to make it clear:
{

belongs to operating system

“operatingsystem_id” => 7,
“operatingsystem_name” => “Rhel 6.3”,

has many organizations

“organizations” => [
[0] {
“id” => 1,
“name” => “ACME_Corporation”,
“title” => “ACME_Corporation”
}
]
}

I know the decision to model it this way has been made based on some
discussion and it also seemed quite fine to me until I started working
with it. After playing with the api when implementing associated
resources for hammer, I find child nodes and the possibility to add more
fields than name and id extremely handy.

In many cases it is useful to display additional information with the
association to help user get oriented (e.g. subnet’s net address,
template’s kind, smart proxy’s url). It is of course possible to
retrieve the desired information by performing additional gets to
appropriate resources but it’s a bit annoying. Another benefit is
consistency and ease of use when you can treat both types of
associations equally.

My proposal is to turn all associations into child nodes displaying
resource’s base.json.rabl view.
What do you think?

Regards
Tomas

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