Il disaccoppiamento briscola ASCIUTTO in REST?

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

Alcune delle classi API Java sono semplicemente dati (bean con proprietà, getter, setter). E almeno alcuni di questi hanno senso trasmettere (in qualche modo) tramite l'API REST come dati (che verranno raggruppati in XML o JSON). Ad esempio, una classe che memorizza informazioni su una macchina server. Devo affrontare la seguente scelta per queste classi di dati: Devo ...

1. esporre la classe Java originale (o una sottoclasse) direttamente nell'API REST, oppure
2. creare una nuova classe di trasferimento dati (modello DTO) appositamente per l'API REST?

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

Argomenti per # 1:

• ASCIUTTO (non ripeterti)
• Più veloce da implementare
• È più facile aggiornare l'API REST

Argomenti per # 2:

• Cosa succede se l'API REST deve essere controllata separatamente dall'API Java? (Questo è un po 'probabile.)
• Cosa succede se ci sono cambiamenti significativi nelle classi di dati Java come rimozione di proprietà, aggiunta di comportamento o modifiche alla gerarchia delle classi? (Anche questo è un po 'probabile.)

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

Mi sto inclinando a partire dal n. 1 e quindi se sorgono problemi passando al n. 2 in seguito, seguendo le agili linee guida per non costruire ciò di cui non puoi dimostrare di aver bisogno. È una cattiva idea; dovrei iniziare con il n. 2 se penso che potrei finire lì comunque?

Mancano importanti argomenti / conseguenze dalle mie liste?

Bella domanda, in poche parole, disaccoppia. Questo è il modo di andare qui, non vuoi essere legato alla versione di Java.

C'è uno scenario che non devi disaccoppiare: se la tua tecnologia consentirà di inviare oggetti non specifici al tipo sul filo, cioè se puoi usare gli attuali oggetti Java ora come YAGNI e la sostituzione con un diverso il tipo che hai personalizzato sarà un semplice drop-in che non romperà 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.

Basta essere molto attenti e attenti che eventuali aggiornamenti alla versione java non cambino nessuno di questi oggetti. Altrimenti, basta disaccoppiare ora e non preoccuparti, credo che dipenda da quanto tempo hai se hai una scelta.

Tuttavia, se le informazioni sul tipo passano attraverso il cavo nel protocollo, un drop-in semplice di nuovi tipi quando cambiano i tipi java sottostanti potrebbe non essere possibile e potrebbe piuttosto essere uno sforzo maggiore. In tal caso, andare su YAGNI ora significa accumulare debiti tecnici e rischi legati alla tua tecnologia sottostante.

Personalmente vorrei solo disaccoppiare ora.

Inoltre, DRY non ci gioca perché non hai scritto i pezzi sottostanti, quindi non stai duplicando il codice e quindi non avrai i dolori dei bug ripetuti all-over che è la preoccupazione principale di DRY (e manutenibilità generale problemi che ancora non avrai perché non hai duplicati da mantenere)

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

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

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

Quando si implementa REST, assicurarsi di creare un'API esterna intuitiva, quindi associarla alle classi del modello di dati interno. Questo ti permette di cambiare ciascuno indipendentemente dall'altro che porta a API che possono durare decenni .

Pertanto, il disaccoppiamento è la strada da percorrere qui.