> 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?
+1 on consistent approach for both types of associations, especially when it makes
easier to work with the API.
– Ivan
···
----- Original Message -----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.