Ciò che mi viene in mente è: non lasciare che l'API RESTful rifletta la ricorsività nell'URL stesso. Vieni a pensarci, la tua risorsa sono solo i documenti.
Se i documenti sono archiviati fisicamente secondo la struttura ricorsiva, creare un mapping su un ID univoco e utilizzare l'ID nell'URL:
/rest/documents/{id}
Ora, se hai i documenti in questo modo:
| DocumentName | DocumentPath | DocumentID |
--------------------------------------------
| abc | /abc | 1 |
| asd | /abc/asd | 2 |
| asd | /asd | 3 |
| boo | /abc/asd/boo | 4 |
| hey | /abc/asd/hey | 5 |
la richiesta consulta questo URL per /abc/asd documento
GET /rest/documents/2
Quindi, ora devi fornire agli utenti della tua API i mezzi per attraversare la tua struttura con poco sforzo. Questo potrebbe essere fatto avvolgendo il tuo payload di risposta (documento) in un oggetto, contenente ulteriori informazioni di attraversamento, come questo:
{
data: { /* your document goes here */ },
parent: {"abc": 1 },
children: [ { "boo": 4 }, { "hey": 5} ]
}
a condizione che ti aspetti che gli utenti non creino troppi documenti in un unico livello, puoi includere un elenco di bambini nella risposta. In caso contrario, potresti offrire all'utente di recuperare ID documento figlio in questo modo, consentendo ad es. per il paging dei risultati tramite parametri querystring:
GET /rest/documents/2/children?page=2&size=50
Infine, parlando dei parametri di querystring, potresti anche fornire le informazioni sul percorso direttamente attraverso i parametri di querystring:
GET /rest/documents?path=somepath&page=1&size=42
Tutti gli approcci menzionati si aspettano che il GET /rest/documents restituisca solo i documenti root.