Primo livello risorsa vs parametro richiesto in RESTful API

Question

Primo livello risorsa vs parametro richiesto in RESTful API

#1 da (1 voti)

1

Progettiamo API RESTful per il nostro sistema. Il 90% delle risorse ha dipendenza da un'altra risorsa chiamata "utente", ad esempio. "Utente" può anche essere usato come risorsa indipendente. Abbiamo trovato due modi su come rispecchiarlo negli URI delle API.

Risorsa di primo livello. Pro: in modo trasparente per i clienti quali risorse dipendono e quali no. Contro: cosa fare se alcune nuove risorse ottengono la dipendenza da "utente" o perversamente perdono tale dipendenza).

/user/guest/token

Parametro richiesto. Pro: facile da aggiungere e rimuovere la dipendenza. Contro: non in modo trasparente per i clienti.

/token?user=guest

Esistono buone pratiche per questo caso?

api rest

posta Nikita Danilov 05.08.2016 - 21:40

fonte

1 risposta

Leggi altre domande sui tag api rest

Avere l'implementatore come una proprietà in un'interfaccia - è una cattiva pratica? Come posso migliorare il mio nuovo processo di progettazione di applicazioni Web?

score 1 · Accepted Answer

Suggerirei una terza soluzione: usa Hypermedia As The Engine Of Application State (HATEOAS).

Fondamentalmente HATEOAS tratta di includere collegamenti nelle rappresentazioni di risorse ad altre risorse. Più specificamente, consente al cliente di sapere quali azioni possono essere intraprese in base ai collegamenti forniti.

Nel tuo caso, non ha gli svantaggi delle soluzioni 1 e 2. Perché non fai affidamento su alcuna gerarchia e è trasparente per il client poiché i collegamenti sono forniti nelle rappresentazioni delle risorse delle "risorse dipendenti".

Diciamo che hai risorse R1 ("token"?), R2 ("guest"?), R3, ecc. che hanno una dipendenza con la tua risorsa "utente". Basta aggiungere un link nelle rappresentazioni di risorse di R1, R2, R3, ecc. All'URI della risorsa "utente" ed è fatto.