Il disaccoppiamento briscola DRY in REST?

Question

Il disaccoppiamento briscola DRY in REST?

#1 da (10 voti)
#2 da (7 voti)
#3 da (6 voti)

19

Sto costruendo un'API REST per esporre la maggior parte delle funzionalità di un'API Java esistente. Entrambe le API sono per uso interno all'interno della mia organizzazione; Non devo progettare per uso esterno. Ho influenza su entrambe le API, ma sto implementando quella di REST. L'API Java continuerà ad essere utilizzata per le applicazioni locali (non è "ritirata"), ma l'API REST verrà utilizzata per un nuovo significativo sviluppo.

Alcune classi dell'API Java sono semplicemente dati (fagioli con proprietà, getter, setter). E almeno alcuni di questi hanno senso trasmettere (in qualche modo) sull'API REST come dati (che saranno scansionati in XML o JSON). Ad esempio, una classe che memorizza informazioni su una macchina server. Mi trovo di fronte alla seguente scelta per queste classi di dati: Do I ...

esporre la classe Java originale (o una sottoclasse) direttamente nell'API REST o
creare una nuova classe di trasferimento dati (schema DTO) specificamente per l'API REST?

In ogni caso avrò classi di trasferimento dati REST; la domanda è se annotare gli originali o crearne di nuovi (che possono essere vicini alle copie degli originali). Potrebbero esserci altre scelte, ma mi concentrerò principalmente su quelle due.

Argomenti per # 1:

ASCIUTTO (non ripeterti)
Più veloce da implementare
È più facile eseguire l'upgrade dell'API REST

Argomenti per # 2:

Che cosa succede se l'API REST deve essere versionata separatamente dall'API Java? (Questo è un po 'probabile.)
Che cosa succede se ci sono modifiche significative alle classi di dati Java come la rimozione di proprietà, l'aggiunta di comportamenti o modifiche alla gerarchia di classi? (Questo è anche un po 'probabile.)

La linea di fondo è che sembra un compromesso tra DRY (n. 1) e disaccoppiamento (n. 2).

Sono propenso ad iniziare con # 1 e poi se i problemi sorgono spostandoci al n. 2 più tardi, seguendo l'agile linea guida di non costruire ciò che non puoi dimostrare di aver bisogno. È una cattiva idea dovrei iniziare con # 2 se penso che potrei finire lassù comunque?

Ci sono argomenti / conseguenze importanti mancanti dai miei elenchi?

java coupling api rest dry

posta Will 22.01.2013 - 16:05

fonte

3 risposte

7

Gli argomenti principali per # 1 sono la facilità di implementazione e gli aggiornamenti, ma soddisfa i tuoi requisiti?

Nei tuoi argomenti per # 2, indicherai che l'API Java e l'API REST potrebbero probabilmente cambiare in modo indipendente. Ciò significa che sono preoccupazioni separate e non ti stai ripetendo utilizzando classi separate. Solo perché due cose sembrano uguali, non significa che sono uguali.

risposta data 22.01.2013 - 16:24

fonte

6

L'API REST non deve seguire la stessa struttura del modello dati

Quando si implementa REST, accertarsi di creare un'API esterna intuitiva e quindi associarla alle classi del modello di dati interno. Questo ti permette di cambiarne ognuna indipendentemente dall'altra che porta a API che possono durare decenni .

Pertanto, il disaccoppiamento è la strada da percorrere qui.

risposta data 23.01.2013 - 11:33

fonte

Leggi altre domande sui tag java coupling api rest dry

Qual è il valore dell'utilizzo del controllo della versione? In Scrum, perché non dovrebbero essere combinati i ruoli Product Owner e ScrumMaster?

score 10 · Accepted Answer

Buona domanda, semplicemente messa, disaccoppia. Questo è il modo per andare qui, non vuoi essere legato alla versione di java.

C'è uno scenario che non si disaccoppia: se la tecnologia consentirà di inviare oggetti non di tipo specifico sul filo, ovvero se è possibile utilizzare gli oggetti java correnti ora come YAGNI e la sostituzione con un tipo diverso da te personalizzato sarà un semplice drop-in che non interromperà nulla a causa delle informazioni sul tipo che vanno oltre il filo. Quindi, fondamentalmente se le informazioni sul tipo non attraversano il filo potresti YAGNI su questo.

Devi solo stare molto attento e attenti che qualsiasi aggiornamento alla tua versione java non cambi nessuno di questi oggetti. Altrimenti, basta disaccoppiare ora e non preoccuparti, immagino dipenda da quanto tempo hai se hai una scelta.

Tuttavia, se le informazioni sul tipo passano attraverso il filo del protocollo, allora un drop-in piatto di nuovi tipi quando i tipi di java sottostanti cambiano potrebbe non essere possibile e potrebbe piuttosto essere uno sforzo più grande. Se è così, andare a YAGNI significa ora accumulare debito tecnico e rischi legati alla tecnologia sottostante.

Personalmente vorrei solo disaccoppiare ora.

Inoltre, DRY non gioca in questo perché non hai scritto i pezzi sottostanti in modo da non duplicare il codice e quindi non avrai il dolore degli errori ripetuti all-over che è la preoccupazione principale di DRY ( e problemi generali di manutenibilità che ancora non avresti perché non hai duplicati da mantenere)