REST Api - Controlla se l'azione è consentita per l'entità

Ci sono alcuni modi per gestirlo, ma generalmente avrai le informazioni sul client prima che il nuovo elemento a discesa sia selezionato, per motivi di esperienza utente.

Da lì, dipende da te come dici al front-end quali azioni sono consentite a un dato elemento, ma un metodo che ho visto è abbastanza pulito usando HATEOAS (Hypertext As the Engine Of Application State).

In questo caso, ogni volta che recuperi una risorsa dal server, includerà tutti i dati, ma includerà anche i metadati sotto forma di collegamenti alle altre azioni supportate. Questo sarebbe un modo semplice per dire al cliente quali altre azioni sono supportate per l'utente corrente e il client potrebbe capire quali pulsanti visualizzare o abilitare.

Sembra che tu abbia due problemi separati.

1. L'utente ha il permesso di eseguire il comando

Un buon modo per attaccare questo è avere un token di accesso con affermazioni dettagliate "canRunActionX", quindi sia il client che il server possono eseguire lo stesso controllo e ottenere lo stesso risultato.

2. L'entità generica X consente l'azione generica Y

In questo caso sembra generalmente improbabile che le azioni per entità cambino molto. Non sarai mai in grado di riformattare un monitor.

O ci sarà una logica chiara che definisce quando l'azione è valida. Non puoi mettere in pausa un video che non sta riproducendo.

Mi piacerebbe questo nel client e risparmiavo il round trip per chiedere qualcosa a cui so già la risposta.

L'approccio HATEOS nel dire al cliente che altro possono fare nella mia esperienza. Il cliente deve essere programmato per comprendere le possibili azioni extra ed essere in grado di chiamarle. Così finisci con tutto ciò che è codificato in ogni caso.

1. Does the user have permission to execute the command

FYI: Attualmente intendiamo risolvere questo problema con un sistema di autorizzazione in BE che verifica se l'utente ha un permesso assegnato se l'azione (pulsante) non viene resa. Il client chiamerà il resto e otterrà tutte le autorizzazioni assegnate e potrebbe controllare ciò che un utente è in grado di fare o meno (tutte le autorizzazioni vengono trasferite all'avvio del client).

2. Does generic entity X allow generic action

I would hardcore this into the client and save myself the round trip to ask something i already know the answer to.

Questo è ciò che facciamo attualmente. Un controllo è codificato in BE e in FE. Sono anche completamente d'accordo con la tua argomentazione contro HATEOS.

BE aggiunge Meta-Informazioni ai dati

Temiamo che businesslogic venga trasferito al client perché assegni come if (entity.field === "State 10" && otherEntity.locked = false ) {....}

La nostra paura è che noi:

• Ripeti noi stessi
• È necessario uno sviluppatore FE e BE per regolare i controlli logici
• Businesslogic potrebbe / verrebbe trasferito al FE
• L'aggiunta di questi metadati ai nostri dati è lenta (vedi sotto)

Quando aggiungiamo i metadati alle nostre entrate come (simile a HATEOS):

[ 
  { 
    _actions: [ xy_allowed: true ], 
    name: "ReportExecutionJob", 
    otherFields: ...
  },
.... 
]

Dobbiamo eseguire il controllo se è consentita un'azione per ogni linea di dati. Questo sarà fatto in BE prima che i dati vengano inviati al client. Quindi un controllo se l'azione "potrebbe" essere consentita viene eseguita in ogni caso, il che avrà un costo (inutile) nel tempo.

L'attivazione / disattivazione di un'azione verrà eseguita quando un utente seleziona un'entità o più entità solo nell'interfaccia utente. Quindi aggiungere i metadati non è forse la soluzione migliore perché non è chiaro se un utente possa / può selezionare questa linea in modo che il controllo sia realmente necessario.

Un altro problema qui è, come già detto, che la FE deve conoscere ogni azione possibile e codice contro questo nome di azione nella FE.

Azione chiedi riposi

Durante una discussione otteniamo anche un'altra Idea.

Dopo che un utente seleziona una voce / voci nell'interfaccia utente. Tutte le azioni che sulla pagina potrebbero fare una richiesta di riposo al BE. (quindi tutte le azioni che non sono renderizzate non causeranno traffico)

Il contenuto della richiesta potrebbe essere ID entità (& Versione in alcuni casi) in BE tutti i controlli sono eseguiti (la logica è solo in BE) e BE restituisce informazioni se l'azione è consentita o meno.

Ma anche qui abbiamo alcuni punti contrari:

• Potrebbe essere lento perché BE ha bisogno di richiedere nuovamente il database per ottenere l'entità per ID
• Potrebbe passare un po 'di tempo prima che l'azione venga abilitata nell'interfaccia utente (altra soluzione abiliterà / disabiliterà l'azione più rapidamente perché le informazioni sono già presenti nell'interfaccia utente)

............................................ ...........................

così per BE aggiunge Meta Infos ai Dati c'è un default (HATEOAS) che può essere usato.

C'è anche una norma per consentire a un'azione di fare una richiesta alla BE per verificare se è consentita o meno?

Codificalo due volte è anche ancora in gara.

Stiamo anche cercando di trovare una soluzione "migliore" (best practice) per farlo e aprire nuove idee o commenti.