Progettazione URI REST per strutture ad albero

C'è un sacco di discussioni sul design dell'URI REST, ma nessuno ha risposto esattamente alla mia domanda.Progettazione URI REST per strutture ad albero

Diciamo che ho alcune liste che contengono attività e/o altri elenchi (list = node e task = leaf).

possiamo avere qualcosa di simile

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

o forse una versione più breve:

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

Ma per quanto riguarda gli alberi davvero profonde?

Pensavo anche sul rapporto padre/figlio che potrebbe essere tradotto come

/lists/{id_list_parent}/{id_list_or_task_child}

ma mi sento come qualcosa che manca ...

Che cosa sarebbe un design intelligente per gli alberi REST URI?

EDIT

Ci scusiamo per la mia risposta in ritardo!

Quindi penso che stavo mescolando 2 esigenze: URI API e URI del browser.

Ecco come vedo le cose:

Sul lato API, avrò solo quelle URI sia per scrivere e leggere i metodi (il '/ id' alla fine non è richiesto, per creare per esempio) :

/lists/id 
/tasks/id

il mio browser tuttavia, avrò qualcosa di simile:

/lists/id/lists/id/tasks/

solo la prima parte (/ lists/id) sarà interpretato dal server, la seconda parte (liste/id/tasks /) wi Verrà utilizzato dal mio lato client javascript per trovare le attività della sottolista della lista ricevuta dal server.

Cosa ne pensi di questo approccio, qualcosa ci sembra sbagliato?

fonte

2012-05-29 greg3z

Dai un'occhiata all'URL su Git Hub https://github.com/twitter/bootstrap/tree/master/docs/templates le cartelle sono nodi ei file sono foglie. Penso che funzioni bene! –

URI non fa parte dell'API REST. REST riguarda il contenuto, non gli URI. Questo dovrebbe consentire di scegliere una sola organizzazione URI e modificarla in seguito. Comunque: perché hai bisogno di/liste/{id_list1}/liste/{id_list2}/liste/{id_list3}/tasks/{id_task1}? Questo sembra portare a task con id 3, quindi non è possibile ridurlo a/liste/{id_list3}/tasks per avere l'elenco delle attività e/tasks/{id_task1} per l'attività all'interno dell'elenco? – jmclem

Grazie per la tua risposta, ma la mia domanda non era esatta, vedi la mia modifica sopra. – greg3z

L'utilizzo dell'URI per applicare questo vincolo non sembra corretto. Accetterei una richiesta PUT con qualche tipo di payload (JSON, XML, ecc.).

PUT /tasklist

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

L'URL sembra indicare che si sta tentando di fare troppe cose qui (IMHO). In genere, si interagirebbe con una singola risorsa, mentre il caso d'uso implica che si sta operando su più risorse contestualmente su più livelli contemporaneamente.

fonte

2012-05-29 22:04:17 hisdrewness

È necessario rappresentare l'albero tramite gli URI? Quando possono semplicemente essere riferimenti ai nodi stessi e le relazioni sono modellate tramite collegamenti nel tipo ipermediale.

Oltre a questo, penso che qualcosa di simile:

/lists/{nodeId}/children

e può restituire un elenco dei bambini diretti al genitore.

Si può anche fare qualcosa di simile:

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

e restituire i prossimi tre livelli dell'albero nel vostro risultato.

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

può restituire l'intero ramo da quel nodo.

fonte

2012-05-29 22:04:20

Progettazione URI REST per strutture ad albero

risposta

Problemi correlati