Progettazione URI per la corrente utente connesso in applicazioni REST

Question

Ho bisogno di un URI nel mio REST API per recuperare l'attuale utente connesso. Di solito uso GET su una risorsa con ID, ma il client non conosce l'ID dell'utente.

ho trovato le seguenti soluzioni:

• Per nome utente

  Questa soluzione utilizza il nome utente anziché l'ID dell'utente.

  Esempio:

  • Bitbucket REST API: GET /user/{userSlug}

• Con risorsa propria

  Questa soluzione ha una risorsa per gli utenti e una risorsa aggiuntiva per clienti registrati.

  Esempi:

  • JIRA REST API: GET /myself

  • GitHub REST API: GET /user

  • Stack Exchange REST API: GET /me

• Con link simbolico

  Questa soluzione ha un collegamento simbolico per l'ID dell'utente.

  Esempio:

  • Confluence REST API: GET /user/current

• Con filtro

  Questa soluzione utilizza un filtro per il nome utente.

  Esempio:

  • JIRA REST API: GET /user?username={username}

quale è più RESTful? Quali sono i pro e i contro?

Answer 1

Spetta a voi. Tutti gli approcci sono perfettamente soddisfacenti dal punto di vista REST.

Secondo la tesi di Roy Thomas Fielding ^*, qualsiasi informazione che può essere nominato può essere una risorsa:

5.2.1.1 Resources and Resource Identifiers

L'astrazione fondamentale di informazioni in REST è una risorsa. Qualsiasi informazione che può essere nominata può essere una risorsa: un documento o un'immagine, un servizio temporale (ad esempio "il tempo di oggi a Los Angeles"), una raccolta di altre risorse, un oggetto non virtuale (ad esempio una persona), e così via . In altre parole, qualsiasi concetto che potrebbe essere il bersaglio del riferimento ipertestuale di un autore deve rientrare nella definizione di una risorsa. Una risorsa è una mappatura concettuale di un insieme di entità, non l'entità che corrisponde alla mappatura in qualsiasi momento particolare. [...]

Quando si utilizza /me, /users/me, /users/myself, /users/current e simili, si dispone di un indicatore di posizione per l'utente autenticato e sarà sempre identificare il concetto di di un utente autenticato , a prescindere di cui l'utente è autenticato.

Per maggiore flessibilità, è inoltre possibile supportare /users/{username}.

Tra l'altro, una situazione simile è stato affrontato in Is using magic (me/self) resource identifiers going against REST principles?

---

^{* Se siete interessati a REST, il chapter 5 della tesi di Fielding è una lettura obbligata.}

Answer 2

Tutti sono ugualmente RESTful. REST non si tratta di URI, si tratta di utilizzando loro restfully.

REST è sul client navigazione stato dell'applicazione. Parte di questo stato può essere chi è l'utente corrente. Tutti gli URL possono essere utilizzati per ottenere questa parte dello stato dell'applicazione.