Percorsi utente restful con token Web

4

Sto provando a creare un'API che ha un accesso che emette un token Web JSON e quindi offre una manciata di risorse ai richiedenti autenticati.

L'utente è un tipo di risorsa, ed è qui che mi confondo sulle rotte. In alcuni casi, gli utenti autenticati ottengono informazioni su altri utenti, come ad esempio:

/api/user/<any user id>/favoriteBooks

Ma nella maggior parte dei casi, gli utenti autenticati possono ottenere informazioni solo su se stessi. Come dovrebbero essere formate quelle richieste?

A: /api/user/1234/homeAddress . 1234 deve essere l'id utente del chiamante e restituisce un errore se l'id utente del percorso non è d'accordo con l'id utente token.

B: /api/user/1234/homeAddress . 1234 deve essere l'id utente del chiamante, ma questa versione lo ignora e restituisce semplicemente le informazioni per l'utente indicato dal token.

C: /api/user/homeAddress . lo stesso di B , tranne per il fatto che questo elimina l'id utente del percorso ridondante che B ignora comunque.

A sembra il più convenzionale, ma contiene un percorso di errore non necessario, B sembra un po 'fuorviante e richiede informazioni ridondanti che vengono ignorate e C è più allettante per la mia intuizione, ma non ho mai visto percorsi come questo. Se una rotta REST deve descrivere completamente la richiesta, anche questa sarà dispari.

C'è una regola o norma strong che posso usare per guidarmi qui?

    
posta user1272965 10.03.2016 - 22:17
fonte

1 risposta

2

L'opzione C è l'approccio corretto.

Esposizione di un ID utente in un endpoint dell'API che già conosce l'ID utente semplicemente perde i dettagli dell'implementazione senza una buona ragione e aggiunge complessità superflua alla chiamata API.

Per rendere la chiamata ancora più chiara, puoi dire:

/api/currentUser/homeAddress
    
risposta data 10.03.2016 - 22:29
fonte

Leggi altre domande sui tag