Devo dividere la mia API per tipo di utente?

Question

Devo dividere la mia API per tipo di utente?

#1 da (11 voti)

7

Diciamo che ho un'app per gestire i team sportivi. I potenziali utenti hanno un ruolo di "allenatore", "giocatore" e "fan". In molti casi dovranno effettuare chiamate API simili per recuperare informazioni come questa:

/api/v1/players    (retrieve all players on their current team)
/api/v1/events     (retrieve all events for their current team)

In altri casi, i ruoli potrebbero avere alcune funzioni disponibili solo per loro, come questo:

/api/v1/opposing_players/:opposing_player_id  (retrieve scouting info about an opposing player, not available to fans)

La mia domanda si riduce a ... Devo espellere esplicitamente l'apis con un prefisso per ogni ruolo? O l'API dovrebbe avere solo un url di base?

/api/v1/coaches/events
/api/v1/fans/events
/api/v1/players/events

o

/api/v1/events

architecture rest authorization load-balancing

posta Msencenb 28.07.2017 - 18:03

fonte

1 risposta

Leggi altre domande sui tag architecture rest authorization load-balancing

In Java, perché fa (unsorted) Set implement Iterable, ma SortedMap no? Modo corretto per inizializzare le variabili in PowerShell

score 11 · Accepted Answer

No non dovresti usare il livello di accesso come parte dell'URI.

Esiste già un modo standard per separare l'API in base all'accesso dell'utente, e questo è con autorizzazione. Tutti gli utenti devono accedere agli stessi endpoint e, in base al ruolo o agli attributi dell'utente autenticato, puoi

Restituisce 401 non autorizzato - Se l'utente non è autenticato
Restituisci 403 Proibito: se l'utente non ha il ruolo o gli attributi appropriati per accedere a una risorsa
Restituisce diversi modelli in base al livello di accesso. Per esempio. l'allenatore può essere autorizzato a vedere la data di nascita di ciascun giocatore, ma i fan non sono ammessi. puoi mostrare / nascondere gli attributi dei modelli in base all'accesso.

Se hai usi uno schema API separato per ogni ruolo, ecco alcuni svantaggi:

Come rappresenti le API uguali per tutti i ruoli?
Deve duplicare molti percorsi quando viene aggiunto un nuovo ruolo (ad esempio, ruolo di amministratore di sistema o gestore di divisione)
La modifica del nome di un ruolo interromperà l'API?
Non intuitivo - se sono un allenatore ma voglio accedere ai dati del giocatore, potrei pensare che dovrei accedere a /api/v1/players ma in realtà ho bisogno di accedere a /api/v1/coaches/players o qualcosa
Come rappresenti i clienti che sono giocatori e fan? Cioè più ruoli
In che modo supporti i client non autenticati? Cioè nessun ruolo
Dati ridondanti - devi controllare che ciascun utente sia autorizzato ad accedere a una risorsa, ma ora devi anche controllare che il ruolo dell'utente corrisponda all'URI. Devi gestire il caso limite di quando il ruolo dell'utente non corrisponde al ruolo URI.
La modifica dell'autorizzazione è una modifica all'interfaccia. Dire che un allenatore va in pensione e diventa un fan. Ora devono modificare tutti gli endpoint che hanno utilizzato per accedere.