API REST - Gestione delle risorse secondarie

Question

API REST - Gestione delle risorse secondarie

#1 da (4 voti)
#2 da (1 voti)

6

Supponiamo che esista una risorsa primaria "/ account" con profilo (nome, ID nazionale, DOB), indirizzi e contatti (email, telefoni). Li considero come risorse secondarie perché non possono esistere senza un account. Per aggiornarli sto pensando a due opzioni

Opzione 1

PUT / account / {accountid} / indirizzo
PUT / account / {accountid} / contatti
PUT / account / {accountid} / profilo

Opzione 2

PUT / account / {accountid}
(A seconda della presenza / assenza di indirizzo / telefono / profilo decidere quali aggiornamenti eseguire)

Sono tentato di usare l'opzione 1 perché dal punto di vista dell'implementazione ciascuno degli aggiornamenti ha la propria logica & flusso di processo. Un URI separato può mantenere l'implementazione più pulita e più efficace; gestibile

Sarebbe scorretto considerare il profilo, l'indirizzo, i contatti come sottorisorse. se è così, quale sarebbe un modo appropriato di rappresentarli
Se possono essere considerate sotto-risorse che tra quelle sopra sono un'opzione appropriata o c'è un'opzione completamente diversa da prendere in considerazione

api-design api rest

posta sbhas 26.01.2016 - 01:13

fonte

2 risposte

Leggi altre domande sui tag api-design api rest

Node.js e applicazioni web ad alta intensità di CPU Il codice non utilizzato influisce sull'assemblaggio dopo l'avvio (ad esempio la memoria)?

score 4 · Answer 1

Would it be incorrect to consider profile,address,contacts as subresources.

No, tutto ciò che ti piace può essere una risorsa secondaria. REST non si preoccupa (una risorsa secondaria è una risorsa) e l'utilizzo dei percorsi è una progettazione URI appropriata per gli elementi gerarchici.

is there a completely different option to be considered?

Potresti tuttavia desiderare modifiche indirizzate a risorse più fini. Il metodo PUT è ottimo per modifiche identi che. È un po 'nervoso per le modifiche parziali: ufficialmente, la specifica http "non definisce come il metodo PUT influenza lo stato del server di origine"; ma è ampiamente compreso che put dovrebbe includere una rappresentazione completa della risorsa, con la creazione o la sostituzione della semantica.

Ad esempio: se si modificano sempre tutti e tre i campi del profilo, utilizzare una singola risorsa per modificare il lotto è appropriato. D'altra parte, se vuoi supportare la sostituzione della data di nascita senza preoccuparti degli altri campi, allora sorprenderai meno persone se scrivi la modifica su una sotto-directory dedicata (ad esempio: / accounts / {accountId} / profile / dob ).

Questa è una preoccupazione generale: aggiorni una risorsa modificandola direttamente, o induci modifiche in essa modificando una sottorisorsa. Ad esempio, sembra che tu abbia più contatti nella tua definizione - potrebbe essere appropriato accettare direttamente le modifiche ai contatti, oppure potrebbe essere che la rappresentazione dei contatti sia invece un riflesso delle modifiche eseguite su contatti / email o contatti / telefono .

score 1 · Answer 2

HTTP e REST non si preoccupano se una risorsa è una "sotto-risorsa", non hanno conoscenza strutturale di un "non può esistere senza" vincolo.

Da una prospettiva di coerenza, se PUT è consentita per una "sotto-risorsa", mi aspetto almeno di poter GET separatamente dalla sua risorsa genitore. Quindi un rigoroso livello 3 approccio REST (HATEOAS) probabilmente raccomanderebbe anche di mettere un link ipermediale alla risorsa Indirizzo in la risposta per GET Account invece di includere direttamente i dati dell'indirizzo lì.