REST Percorsi in base ai ruoli

Question

REST Percorsi in base ai ruoli

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Attualmente sto lavorando a un progetto che utilizzerà un'API REST ed è esattamente quello su cui sto lavorando e sto usando i nodijs con express, mongodb e mangusta.

Ho utenti che possono avere 4 diversi ruoli: utente, segretario, lavoratore e manager. Diciamo che possono tutti accedere al documento del kit ma possono fare diverse azioni verso di esso a seconda dello stato corrente dell'oggetto. L'utente richiede una riparazione ed è solo in grado di visualizzare le proprie richieste, il lavoratore può solo visualizzare / agire se è stato approvato dal gestore e il manager può approvare / visualizzare tutte le richieste di riparazione esistenti.

Attualmente stavo usando i seguenti endpoint:

get /api/repairs - all the items, can be viewed by the manager
get /api/repairs/me - all the items created by the user that is accessing it
get /api/repairs/me/:id - detail of an item created by the user that is accessing it

Quali percorsi devo creare per gli altri ruoli? Questa è la prima volta che lavoro con questo e anche se ho cercato le migliori pratiche, non posso davvero dire quale sia il migliore in questo caso. Grazie in anticipo.

Ci ho pensato, ma non sono proprio sicuro che sia la migliore pratica.

'/api/users/repairs/' GET
'/api/users/repairs/:id' GET
'/api/workers/repairs/' GET
'/api/workers/repairs/:id' GET
'/api/workers/repairs/:id/complete' PATCH - to complete a repair request 
'/api/workers/repairs/:id/reschedule' PATCH - to reschedule a request
'/api/managers/repairs/' GET
'/api/managers/repairs/:id' GET
'/api/managers/repairs/:id/' PATCH - to edit the request

design-patterns rest

posta André 08.10.2018 - 18:33

fonte

3 risposte

Leggi altre domande sui tag design-patterns rest

Pure funzioni con una connessione a un sistema Utilizzo dei tasti primari Autoincrement come chiavi esterne e codici univoci

score 1 · Answer 1

Se le seguenti operazioni

/api/users/repairs
/api/workers/repairs
/api/managers/repairs

ogni return Repair[] , quindi userò semplicemente /api/repairs e restituirò le riparazioni accessibili all'utente che effettua la richiesta.

Creerei solo percorsi e operazioni separati se la forma della risposta è diversa, ad es.

/api/users/repairs restituisce UserRepair[]
/api/workers/repairs restituisce WorkerRepair[]
/api/managers/repairs restituisce ManagerRepair[]

score 1 · Answer 2

Secondo me, l'unica strada che dovresti usare è:

OTTIENI : / api / riparazioni

PATCH : / api / repairs

Sì, solo uno . Dici che vuoi estrarre i dettagli da esso? Usa il metodo GET,

OTTIENI : / api / riparazioni [Restituisce ciò che è pubblico]

OTTIENI : / api / repairs / {sessionKey / secretKey} [Restituisce ciò che appartiene all'utente]

OTTIENI : / api / repairs / {sessionKey / secretKey} & {id} [Restituisci elemento per id appartiene all'utente] *

Lo stesso vale per la patch (se devi aggiornare qualcosa), solo il metodo REST sarà diverso, il tuo backend dovrebbe essere automaticamente in grado di distinguere la differenza in termini di metodo REST e query fornite.

Nota: non eseguire query sulle informazioni in PATCH invece di fornirle nel corpo

score 0 · Answer 3

REST non si cura di quale ortografia usi per le tue risorse.

In una hypermedia api (che è ciò che REST significa veramente ), ai clienti non interessa neanche; avrebbero semplicemente seguito tutti i collegamenti forniti dal server.

Let's say they can all access the kits document but they can do different actions towards it depending on the item's current state

Ti incoraggio a rivedere il discorso di Jim Webber REST nel grande .

HTTP is the application protocol for a 1950s office, where all work is transacted by politely placing documents in in-trays; and then some side effect of placing that document in an in-tray causes some business activity to occur.

Il tuo processo aziendale è fondamentalmente una grande cartella manila con un mucchio di moduli. Ecco la richiesta di riparazione, ecco l'approvazione del responsabile, ecco la fattura, ecco l'ordine di lavoro e così via.

/api/repairs/:id/request
/api/repairs/:id/approval
/api/repairs/:id/work-order
/api/repairs/:id/invoice
/api/repairs/:id/schedule
...

Quindi, ad esempio, solo il gestore è autorizzato a PUT / PATCH la risorsa di approvazione, e fino a quando non viene eseguita la risorsa ordine di lavoro restituisce 403 o 404 se l'operatore tenta di accedere all'ordine di lavoro prima che abbia è stato approvato, il cliente può vedere solo le risorse che è autorizzata a vedere e tutti ottengono una grande 403 se colorano fuori dalle righe.