Tree or flat structure to represent parent child relationships?

[Spyros Ioakeimidis]

Hello!

I have a parent child relationship between two items of the same entity. What do you think is the best way to represent this relationship in the response?

Using a flat structure with something like a "parent" field?

{
    "items": [
        {
            "item": "id_of_item_1"
        },
        {
            "item": "id_of_item_2",
            "parent": "id_of_item_1"
        }
    ]
}

Or using a tree structure?

{
    "items": [
        {
            "item": "id_of_item_1",
            "children": [
                {
                    "item": "id_of_item_2"
                }
            ]
        }
    ]
}

I can imagine that using a tree structure will force the clients to use recursion to figure out relationships. While having a flat structure, loop through the array is enough to create the relationships (if this is required).

Any ideas?

Thank you in advance!

[Jørn Wildt]

Personally I would prefer the tree structure as it saves me from building it up later on if needed - and using recursion for that would be a very natural action. It is also very easy to show a flat list using depth-first recursion afterwards.

Can the tree grow very big? If so you might want to return one level only - with links to child sub-trees and parent item. The client can then expand the tree as the end-user clicks open/close icons for the sub-trees.

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Vijay Aravamudhan]

hi,

There are some questions that come to mind:

1) Is your api going to support streaming?

2) Are your consumers going to (mostly) use the full tree or just a part of it? (I know that APIs should not be consumer-aware, but, one can argue to the extremes on that topic)

I would prefer something akin to HAL - where each element knows the link to the next, and as a consumer, I dont need the full tree to continue with my logic. In this context, what I am saying is that the flat structure is something that I would prefer. That being said, I do think that some aggregation metadata can be built into the top-level node about its children, say for eg, count (useful for pagination scenarios, etc)

Thanks,
Vijay

[Spyros Ioakeimidis]

Hi Jørn!

The tree will not grow very big. Currently, the maximum level of depth will be one. So in that case, you would prefer tree structure. I can see your point. Though, in my opinion a flat structure seems easier to manipulate on client side by third party developers. 

[Spyros Ioakeimidis]

Hey Vijay,

1) No it is not intended to be used as a stream.

2) The consumers are supposed to use the full tree. This is however kind of optional. The parent relationship is information that client can choose not to show.

I am using HAL+JSON as a response format for the API. So I agree that a flat structure with parent links helps a lot with the navigation.

[Johan Groenen]

Hey Spyros,

The pragmatic approach would be to send it in exactly the way you are going to use it.

But I would prefer a "flat" solution, as follows:

GET /items

{ "entities": [ <item1>, <item2> ] }

You can then add a filter:

GET /items?parent_id=1

If you need the expanded tree, you can add a parameter to the root item query

GET/items/1?expanded=true

GET/items/root?expanded=true (use "root" slug for root element if id isn't one)

This enables you to get a expanded subtree too.

Of course, if your tree is very, very big and only accessed as a while, it makes more sense to make expanded=true the default and just call it on root once.

Op maandag 19 januari 2015 13:26:07 UTC+1 schreef Spyros Ioakeimidis: