REST URI design for tree structures

Question

There is a lot of discussions out there about REST URI design, but none replied precisely to my question.

Let's say I have some lists that contains tasks and / or other lists (list = node and task = leaf).

We can have something like

/lists/{id_list1}/lists/{id_list2}/lists/{id_list3}/tasks/{id_task1} 

or maybe a shorter version :

/lists/{id_list1}/{id_list2}/{id_list3}/{id_task1}

But what about really deep trees ?

I was also thinking about the parent/child relation which could be translated like

/lists/{id_list_parent}/{id_list_or_task_child} 

but I feel like something's missing...

What would be a smart design for REST URI trees ?

EDIT

Sorry for my late answer !

So I think I was mixing 2 needs : API URIs and browser URIs.

Here's how I see things :

On the API side, I'll have only those URIs for both write and read methods (the '/id' at the end is not required, for create for instance) :

/lists/id
/tasks/id

On my browser however, I'll have something like this :

/lists/id/lists/id/tasks/

Only the first part (/lists/id) will be interpreted by the server, the second part (lists/id/tasks/) will be used by my client side javascript to find the tasks of the sublist of the list received from the server.

What do you think of this approach, does something feel wrong in it ?

Answer 1

Is there any need to represent the tree via the URIs? When they can simply be references to the nodes themselves and the relationships are modeled via links in the hypermedia type.

Other than that, I think something like:

/lists/{nodeId}/children

and it can return a list of the direct children to the parent.

You can also do something like:

/lists/{nodeId}/children?depth=3

and return the next three levels of the tree in your result.

/lists/{nodeId}/children?depth=infinite

can return the entire branch from that node.