REST Diseño de URI para estructuras de árbol

Hay muchas discusiones sobre el diseño de URI de REST, pero ninguna respondió con precisión a mi pregunta.REST Diseño de URI para estructuras de árbol

Digamos que tengo algunas listas que contienen tareas y/u otras listas (list = node y task = leaf).

Podemos tener algo como

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

o tal vez una versión más corta:

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

Pero ¿qué pasa con árboles muy profundas?

También estaba pensando acerca de la relación padre/hijo que podría ser traducido como

/lists/{id_list_parent}/{id_list_or_task_child}

pero siento que falta algo ...

Lo que sería un diseño inteligente para árboles REST URI?

EDIT

¡Perdón por mi respuesta tardía!

Así que creo que estaba mezclando dos necesidades: API URI y URI del navegador.

Así es como veo las cosas:

En el lado de la API, voy a tener sólo aquellos URIs tanto para escribir y leer métodos (el '/ id' al final no se requiere, para crear, por ejemplo) :

/lists/id 
/tasks/id

en mi navegador, sin embargo, voy a tener algo como esto:

/lists/id/lists/id/tasks/

Sólo la primera parte (/ listas/id) será interpretado por el servidor, la segunda parte (listas/id/tasks /) wi Seré utilizado por mi lado del cliente javascript para encontrar las tareas de la sublista de la lista recibida del servidor.

¿Qué piensas de este enfoque, algo se siente mal en él?

Fuente

2012-05-29 greg3z

Eche un vistazo a la url en Git Hub https://github.com/twitter/bootstrap/tree/master/docs/templates las carpetas son nodos y los archivos son hojas. ¡Creo que funciona bien! –

URI no es parte de la API REST. REST es sobre contenido, no URI. Esto debería permitirle elegir libremente una organización de URI y cambiarla más adelante. De todos modos: ¿por qué necesitas/lists/{id_list1}/lists/{id_list2}/lists/{id_list3}/tasks/{id_task1}? Esto parece llevar a la tarea con id 3, por lo que no podría reducirse a/lists/{id_list3}/tasks para tener la lista de tareas, y/tasks/{id_task1} para la tarea dentro de la lista? – jmclem

Gracias por su respuesta, pero mi pregunta no fue exacta, consulte mi edición anterior. – greg3z

El uso del URI para hacer cumplir esta restricción no parece correcto. Aceptaría una solicitud PUT que tenga algún tipo de carga útil (JSON, XML, etc.).

PUT /tasklist

lists: [{ 
    id: 1234, 
    id: 12345, 
    tasks: [{ 
     id: foo, 
     id: bar, 
     id: baz 
    }] 
}]

La URL parece indicar que se está tratando de hacer demasiado aquí (en mi humilde opinión). Por lo general, estaría interactuando con un único recurso, mientras que su caso de uso implica que está operando en varios recursos contextualmente escalonados a la vez.

Fuente

2012-05-29 22:04:17 hisdrewness

¿Hay alguna necesidad de representar el árbol a través de los URI? Cuando pueden simplemente ser referencias a los nodos mismos y las relaciones se modelan a través de enlaces en el tipo hipermedia.

Aparte de eso, creo que algo como:

/lists/{nodeId}/children

y puede devolver una lista de los hijos directos a los padres.

También puede hacer algo como:

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

y devolver los siguientes tres niveles del árbol en su resultado.

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

puede devolver toda la bifurcación desde ese nodo.

Fuente

2012-05-29 22:04:20

REST Diseño de URI para estructuras de árbol

Respuesta

Cuestiones relacionadas