Come modellare una vista di amministrazione su un'API di ripristino

Abbiamo un'API ReST più o meno "tipica" che consente ai client di interagire con un sacco di risorse, ad esempio Mappe e dispositivi. Un client autenticato può ottenere un elenco di mappe, può scaricare una mappa, caricare una mappa e fare cose simili con i dispositivi.

Attualmente le risorse hanno URI modellati come questo:

• Recupera tutte le tue mappe: GET /maps
• Recupera una mappa specifica: GET /maps/1234
• Carica una mappa (caricamento di un modulo multipart): POST /maps
• etc

Molto semplice.

Tutte queste richieste sono nel contesto di un client autenticato, il che significa che un FOO del client non può vedere le mappe della BAR del cliente e se ottieni la raccolta / maps, ovviamente vedi solo le tue mappe.

Ora vogliamo creare una Admin-UI in cima a questo servizio. Ciò significa che un utente con un determinato ruolo (un "Amministratore") dovrebbe essere in grado di accedere a tutti gli account ed eseguire operazioni come eliminare account, crearne di nuovi, ecc. Questo non è un problema, possiamo solo aggiungere una nuova risorsa chiamata "account" "e modella questa API.

Tuttavia, l'amministratore deve anche essere in grado di interagire con i contenuti di qualsiasi account a cui ha accesso. Ad esempio, deve essere in grado di vedere quali mappe un account FOO ha e possibile modificare quella raccolta.

Ora abbiamo il problema che gli URI delle risorse originali non sono più sufficienti per esprimere questo, poiché abbiamo bisogno di modellare in qualche modo l'account di destinazione.

Come lo progettiamo? Cosa ha più senso? Quali sono alcuni modelli comuni?

Le opzioni che abbiamo discusso sono:

1. Disponi di un secondo set di URI che modellano le stesse risorse delle risorse secondarie di un account, ad esempio /account/FOO/maps anziché / maps. Questo ha lo svantaggio di avere un sacco di duplicazione e sembra non tipico. Inoltre, non consente operazioni su più account. Questo potrebbe non essere un requisito attuale, ma sembra ragionevole aspettarsi.
2. Modellare l'account "target" come una sorta di parametro ortogonale (un'intestazione? Un parametro matrice? Un parametro URL?) e assumere che quando questo parametro non è presente, deve essere utilizzato l'account del client corrente. Ciò consentirebbe ai client correnti di continuare a funzionare normalmente e il client admin può aggiungerli alla richiesta. Es .: GET /maps;account=FOO

Ci manca qualcosa di ovvio? Come stanno facendo le altre persone?