Permessi per app a pagina singola rappresentati tramite API RESTful

1

Sto cercando di capire il modo giusto per gestire le autorizzazioni in una singola app che parla direttamente con diverse API RESTful, che implementano HATEOAS.

Ad esempio:

"Come utente della mia applicazione posso visualizzare, avviare e mettere in pausa i lavori ma non fermarli."

L'API di restanza sottostante ha la seguente risorsa:

/jobs/{id} 

Che accetta GET e PUT. GET restituisce un modello di lavoro e il PUT accetta un modello di lavoro come un corpo della richiesta nel formato:

{
 "_links" : {
     "self" : "/jobs/12345678"
 }
 "id" : 12345678,
 "description" : "foo job",
 "state" : "STOPPED"
}

Gli stati di lavoro accettati possono essere: dormienti | correndo | in pausa | fermato.

Il requisito dice che sull'interfaccia utente devo avere i pulsanti:

START, PAUSE, STOP

... e vengono visualizzati solo in base alle autorizzazioni dell'utente connesso.

Dal punto di vista dell'API tutto funziona come la logica sottostante sul server, assicurando che l'utente non possa aggiornare lo stato a uno stato STOPPED quando viene fatta una richiesta (forse un 401 viene restituito).

Qual è il modo migliore per informare l'app / l'interfaccia utente delle autorizzazioni dell'utente, in modo che possa nascondere tutti i pulsanti che l'utente non ha il permesso di agire?

L'API dovrebbe fornire un elenco di autorizzazioni, ad esempio:

{
 "_links" : {
     "self" : "/permissions",
     "jobs" : "/jobs"
 }
 "permissions" : { 
     "job" : ["UPDATE", "DELETE"], 
     "job-updates" : ["START", "PAUSE"] 
  }
}

OPPURE se l'API cambia in modo tale che le autorizzazioni si riflettano nei link HATEOS, può essere qualcosa del tipo:

{
 "_links" : {
     "self" : "/jobs/12345678",
     "start" : "/jobs/12345678/state?to=RUNNING", 
     "pause" : "/jobs/12345678/state?to=PAUSED", 
 }
 "id" : 12345678,
 "description" : "foo job",
 "state" : "DORMANT"
}

O dovrebbe essere fatto in un modo completamente diverso?

    
posta Lewis 10.07.2014 - 01:22
fonte

1 risposta

1

Il tuo secondo approccio, incluso nel modello di lavoro, collega solo le azioni che l'utente ha effettivamente il diritto di esibire, è quello che vorrei prendere.

  • Mantiene l'attenzione sulla risorsa e sulle azioni che possono essere eseguite su di esso, il che rende concettualmente sia relativamente semplice sia un buon adattamento per lo stile architettonico REST.

  • Mantiene sul server tutta la logica che circonda gli utenti e le autorizzazioni invece di diffonderne frammenti su server e client.

  • Rispecchia fedelmente il tuo design sul lato utente delle cose, in cui i pulsanti a cui l'utente non deve fare clic semplicemente non vengono presentati.

risposta data 10.07.2014 - 02:52
fonte

Leggi altre domande sui tag