Progettazione REST - Devo restituire dati descrittivi che possono essere impliciti o dedotti

Question

Progettazione REST - Devo restituire dati descrittivi che possono essere impliciti o dedotti

#1 da (2 voti)
#2 da (0 voti)

3

Sto cercando il principio della migliore pratica qui. Come parte del mio REST Api, sto restituendo alcune informazioni di base per un utente. Diciamo che l'utente può essere un "proprietario" di un'azienda, nel qual caso hanno pieno accesso a tutte le risorse dell'azienda. Oppure avrebbero potuto ottenere l'accesso delegato a determinate parti dell'azienda. Ora ho queste due scelte di JSON da restituire

se l'utente è un proprietario ...

{
     companyId : "123",
     companyName: "Acme",
     isOwner: true,
     delegatedAuthority : null 
}

se l'utente ha delegato l'accesso a determinate risorse dell'azienda ...

{
     companyId : "123",
     companyName: "Acme",
     isOwner: false,
     delegatedAuthority : 
        {
            // An object that provides all the details about the delegation.
        }
}

Ovviamente, da una implementazione perspecitiva, farei qualcosa di semplice come impostare isOwner = delegatedAuthority == null dietro le quinte.

Ma dovrei anche restituire la bandiera? Da una prospettiva esplorativa o descrittiva, sembra una cosa carina da restituire. Potrebbe essere utile per qualcuno che costruisce un consumatore che potrebbe non avere familiarità con l'API o il dominio. Ma per qualcuno che abbia familiarità con l'API / dominio, sembra che potrei violare DRY e restituire informazioni ridondanti. Si sentirebbero ora costretti a scrivere codice di controllo degli errori per assicurarmi di non mentire a loro e restituire sia isOwner = true che delegatedAuthority != null

Quali sono i principi da prendere in considerazione e da valutare?

api-design rest

posta Chaitanya 23.02.2017 - 02:53

fonte

2 risposte

Leggi altre domande sui tag api-design rest

Problemi con TDD nella progettazione di servizi / depositi Configurazione del comportamento dell'entità DDD

score 2 · Answer 1

È sempre ovvio? Cosa succede se ciò che determina isOwner cambia dietro le quinte?

Ci sarà un sacco di codice client che si interromperà, se l'associazione tra i due campi è scomparsa.

Pensando a un'interfaccia, manterrò isOwner. Se la relazione sottostante cambia, i tuoi clienti non si interromperanno.

score 0 · Answer 2

È opportuno costruire la logica aziendale in un unico posto. Nel tuo caso la logica di business è: se quella struttura dati delegatedAuthority è mancante, la persona è proprietaria.

Dovresti incapsulare la logica in un metodo. Spetta a te se lo fai dal lato server o lato client. Se è implementato sul lato server, restituisce il valore booleano nella chiamata REST. Puoi anche solo restituire la struttura dei dati, ma poi ti suggerisco di implementare la logica nel lato client. Ad esempio, non stai controllando ovunque if delegatedAuthority != null ma hai un pezzo di codice che consuma l'endpoint REST e fornisce la funzionalità isOwner () per te.

D'altra parte - potresti anche ricostruire la tua API in modo che invece di isOwner tu stia restituendo role che potrebbe contenere anche altri ruoli che sono attualmente memorizzati in delegatedAuthority . Ad esempio, restituire la stessa struttura dati per proprietari e altre persone. Ma ancora una volta - questa non è solo una questione di singolo endpoint, ma piuttosto una decisione su dove costruire la tua logica di business in generale.