/users?role=admin , dove admin è probabilmente una specie di slug
vs
/users?role=2 , dove 2 si riferisce alla nostra chiave primaria della tabella del dizionario dei ruoli interni.
Quale dei due è preferibile?
/users?role=admin , dove admin è probabilmente una specie di slug
vs
/users?role=2 , dove 2 si riferisce alla nostra chiave primaria della tabella del dizionario dei ruoli interni.
Quale dei due è preferibile?
/users?role=admin, where admin is probably some kind of slug vs /users?role=2, where 2 refers to our internal roles dictionary table primary key.
Which of the two is preferred?
Quale dei due è più probabile che funzioni quando si modifica l'implementazione sul server?
Jim Webber:
URIs do NOT map onto domain objects - that violates encapsulation. Work (ex: issuing commands to the domain model) is a side effect of managing resources. In other words, the resources are part of the anti-corruption layer.
Parte del punto di REST è che il client e il server comunicano tramite messaggi. Le risorse sul server agiscono come un adattatore o livello anti-corruzione, trasformando i messaggi in qualcosa che il modello di dominio comprende.
Cool URI non cambia ; sono accoppiati alla semantica del messaggio piuttosto che all'implementazione.
I valori nominati sono più debugabili, il che è un grande vantaggio.
Se il nome del ruolo può essere fornito dall'utente e non è limitato ad alcuni preset, è necessario considerare due problemi:
Il nome potrebbe includere dati sensibili per la sicurezza. Questo è problematico se l'URL dovesse essere visibile in altri contesti. A seconda degli errori restituiti, questo potrebbe anche essere utilizzato per verificare l'esistenza di un ruolo specifico.
I nomi potrebbero non essere unici. O i nomi hanno uno scope in modo che lo stesso nome possa fare riferimento a ruoli diversi in ambiti diversi, o hai bisogno di un ID numerico.
Se tutti i ruoli sono integrati ma utilizzano ID invece di nomi mnemonici, allora sorge la domanda su come i clienti devono sapere quale ID devono usare.
Se l'API è puramente interna (e i client API possono essere modificati insieme all'API), ciò è meno importante, ma l'utilizzo dell'ID ruolo corretto è ancora una possibile fonte di errori.
TLDR: non importa.
Se la tua API è pubblica, dovrai fornire la documentazione che combina gli ID con i nomi. Se la tua API è privata, come hai detto qualcun altro, avrai la possibilità di cambiare il codice del client come preferisci, quindi le modifiche all'API non interromperanno le cose.
Personalmente utilizzerei gli ID a causa delle limitazioni della stringa di query, dell'efficienza della larghezza di banda (minuscola) e della mancanza di necessità di associare il nome all'ID sul server.
I vantaggi del debug che qualcun altro ha citato sono facilmente ottenuti facendo in modo che i gestori degli errori spieghino cosa non funziona mentre si esegue la modalità di debug.