Sto progettando un REST API per un sistema di gestione dei documenti . Per rendere l'API più naturale, ho pensato di utilizzare l'identificatore naturale per un file, che è il suo percorso (di solito con barre "/" in avanti), e non qualcosa come un ID artificiale come un UUID.
Ovviamente, un utente identifica un file tramite il suo percorso:
/path/to/file.txt
Sfortunatamente, questo si scontra con una progettazione API comune e buona.
Funzionerebbe:
Retrieving a file: GET /api/v1/files/<path/to/file.txt>
Tuttavia, altri metodi che vorresti avere diventeranno un po 'problematici:
Retrieving a file list of a folder: GET /api/v1/folders/<path/to/folder>/files
I miei pensieri finora:
- evita gli identificatori univoci con "/" interamente e usa un UUID artificiale (come Alfresco usa NodeId / NodeRefs). Ciò aggiungerebbe un altro livello di astrazione ad esso, dove un ID univoco non è molto naturale dal punto di vista del dominio aziendale
- non utilizzare l'identificatore nel percorso dell'URL ma in un parametro (rispetto ai buoni schemi di progettazione dell'API)
- (richiedere agli utenti API di sostituire / con un altro personaggio ovviamente non è un'opzione)
Naturalmente, i file e le cartelle così come li conosciamo da un file system, sono naturalmente identificati dal suo percorso. In quel caso particolare, si potrebbe obiettare che se qualcuno vuole usare il percorso come identificatore, piuttosto che il modo corretto di farlo:
Retrieving a file: GET /api/v1/files/<path/to/file.txt>
in realtà sarebbe:
Retrieving a file: GET /api/v1/folders/<path>/folders/<to>/files/<file.txt>
se vogliamo essere veramente corretti qui.
Aggiornamento: voglio chiedere alla community le migliori pratiche ed esperienze qui - specialmente quando Dropbox e Google Drive utilizzano entrambi due approcci diversi (vedi prima risposta e commenti sotto): DropBox sta utilizzando il percorso mentre Google Drive è utilizzando gli ID.