Progettazione dell'API REST: POST (userId implicito) vs PUT (userId esplicito)

Ho visto buone API progettate in entrambi i modi. Da un lato, fornendo l'ID utente in autenticazione e l'URL sembra ridondante.

D'altra parte, potrebbe essere più coerente avere un ID esplicito nell'URL se ci sono anche modi per un utente di guardare i dati pubblici di un altro utente o si sta utilizzando la stessa o una API simile nei client che bisogno di ottenere dati per molti utenti. In questo modo, fornisci sempre un ID utente nell'URL, indipendentemente dal fatto che sia ridondante o meno.

Per inciso, ho visto anche le API in cui puoi usare la parola "me" nell'URL per fare riferimento all'utente autenticato.

Ci sono fondamentalmente due domande diverse in una. Fammi semplificare e riformattarli:

1. Se hai userId una volta come informazioni di autenticazione e una volta come parte di un oggetto di dati che si dovrebbe vincere?

Nessuno di loro dovrebbe vincere. Questi sono due userId diversi uno è l'utente che esegue l'azione un altro è l'oggetto utente utente come soggetto dell'azione. Pensa ad admin rinominando un altro utente. nel caso di un utente normale dovresti confrontare questi due ID e restituire qualche codice di stato di errore se differiscono.

2. Come progettare una chiamata API al percorso della risorsa che modifica la posizione stessa? Esempio: PUT in /users/{name} potrebbe potenzialmente modificare name .

Ecco perché hai userId . Presumo che userId non cambi. Quindi usa questa posizione a PUT per aggiornare l'utente. Per comodità, puoi fornire il reindirizzamento della risposta sulla posizione /users/{name} alla posizione permanente corrispondente della risorsa.

Il tuo GET /news si nasconde essenzialmente con quali risorse stai lavorando dietro alle informazioni di autenticazione (che di solito vengono trasferite al server usando sessionId). Questo non è RESTful, in quanto dovresti definire esplicitamente quali risorse stai lavorando nell'URL.

La versione corretta è:

GET /news?userId=:userId

Anche in questo caso si usano le informazioni di autenticazione per convalidare / autorizzare la richiesta, ma questo è OK dal punto di vista REST.

L'unica eccezione a questa regola è il POST quando si crea una nuova entità mentre la chiave è generata sul server - in questo caso si omette l'ID perché non lo si conosce ancora. Ha alcuni svantaggi (non idempotente), l'utilizzo di PUT con la chiave generata dal client è migliore.