Come rappresentare una proprietà di sola lettura in un'API REST

Question

se si dispone di un REST API che è hypermedia-driven (hateoas) si può facilmente cambiare il comportamento di un cliente, includendo o omettendo i collegamenti nella risposta (_links). Ciò consente al cliente di dimenticare completamente le autorizzazioni di test per le operazioni possibili nello stato corrente di resource (il collegamento all'operazione è presente o meno).

Inoltre si può lasciare fuori le proprietà nella risposta se l'utente corrente non dispone dell'autorizzazione per vederlo.

Tale autorizzazione modo è fatta interamente sul server (e controlla le azioni e le proprietà che sono ammissibili per l'esecuzione/vista).

Ma cosa succede se voglio un read-only proprietà? Non è un problema per RESTAPI ignorare la proprietà se è presente nella richiesta (_POST_ O _PUT_). semplicemente non verrà salvato. Ma come può un client di distinguere tra scrittura e sola lettura proprietà di presentare gli opportuni controlli utente (come un campo di immissione disabile in HTML)?

L'obiettivo è di non avere mai le autorizzazioni di client request di un utente, ma di disporre di una risorsa completamente client/frontend basata su risorse.

Qualsiasi aiuto è molto apprezzato :-)

Answer 1

Se ho frainteso la tua domanda, mi scuso in anticipo. Con questo detto ...

Ma come può un client di distinguere tra scrittura e lettura sola proprietà di presentare gli opportuni controlli utente (come un disabile campo di input in HTML)

Bene , ci sono più soluzioni a questo. Il più semplice che posso personalmente pensare è quello di rendere ogni proprietà di un oggetto che ha una struttura semplice di qualcosa come:

... 

    someProperty: { 
     value: 'some value', 
     access: 'read-only' 
    }, 
    someOtherProperty: { 
     value: 'some value', 
     access: 'write' 
    } 
    ... 

È ovviamente possibile ottenere creativo come si desidera con il modo di rappresentare il livello di "accesso" della proprietà (usando enumerazioni, booleani, cambiando access per essere isReadOnly o qualsiasi altra cosa).

Successivamente, la persona che utilizza l'API ora sa di essere di sola lettura o meno. Se inviano un valore di "scrittura" per una proprietà "di sola lettura" come parte del payload POST, allora non dovrebbero aspettarsi niente di meno di una risposta 403.

Edit: Nel caso in cui non si può alterare le proprietà in questo modo, ci sono una serie di altri modi si può ancora raggiungere questo obiettivo:

• documentazione scrittura che spiega che cosa accedere ad ogni proprietà ha
• crea un percorso che l'utente può inviare a 1 o più proprietà per ricevere una risposta che indica il livello di accesso di ogni proprietà (risposta: {propName: 'sola lettura', propName2: 'scrivi', ecc.)
• Restituisce una proprietàAccesso mappa come parte della risposta (mappatura delle proprietà ai livelli di accesso).

fine giornata, hai solo bisogno di un modo per mappare una proprietà con un livello di accesso. tuttavia ciò dipende da quali sono le restrizioni e i requisiti per l'API, quali modifiche è possibile apportare e cosa è accettabile per i client e i requisiti aziendali.