Apakah decoupling trump DRY di REST?

Saya sedang membangun REST API untuk mengekspos sebagian besar fungsionalitas Java API yang ada. Kedua API untuk penggunaan internal dalam organisasi saya; Saya tidak harus mendesain untuk penggunaan eksternal. Saya memiliki pengaruh atas kedua API tetapi menerapkan yang REST. Java API akan terus digunakan untuk aplikasi lokal (tidak sedang "dihentikan"), tetapi REST API akan digunakan untuk pengembangan baru yang signifikan.

Beberapa kelas Java API hanyalah data (biji dengan properti, getter, setter). Dan setidaknya beberapa dari ini masuk akal untuk mengirimkan (dalam beberapa bentuk) melalui REST API sebagai data (yang akan disusun ke XML atau JSON). Misalnya, kelas yang menyimpan info tentang mesin server. Saya dihadapkan dengan pilihan berikut untuk kelas data ini: Apakah saya ...

1. mengekspos kelas Java asli (atau subkelas) langsung di API REST, atau
2. membuat kelas transfer data baru (pola DTO) khusus untuk REST API?

Either way saya akan memiliki kelas transfer data REST; pertanyaannya adalah apakah akan membuat anotasi dokumen asli atau membuat yang baru (yang mungkin dekat dengan aslinya). Mungkin ada pilihan lain, tetapi saya akan fokus terutama pada keduanya.

Argumen untuk # 1:

• KERING (jangan ulangi diri Anda sendiri)
• Lebih cepat diimplementasikan
• Lebih mudah untuk meningkatkan API REST

Argumen untuk # 2:

• Bagaimana jika REST API perlu diversi secara terpisah dari Java API? (Ini agak mungkin.)
• Bagaimana jika ada perubahan signifikan pada kelas data Java seperti penghapusan properti, penambahan perilaku, atau perubahan hierarki kelas? (Ini juga agak mungkin.)

Intinya adalah bahwa tampaknya seperti tradeoff antara KERING (# 1) dan decoupling (# 2).

Saya condong ke arah mulai dengan # 1 dan kemudian jika muncul masalah pindah ke # 2 nanti, mengikuti pedoman lincah tidak membangun apa yang Anda tidak dapat membuktikan Anda butuhkan. Apakah ini ide yang buruk; haruskah saya mulai dengan # 2 jika saya pikir saya akan berakhir di sana?

Apakah ada argumen / konsekuensi utama yang hilang dari daftar saya?

Pertanyaan yang bagus, sederhananya, decouple. Itulah cara menuju kesini, Anda tidak ingin terikat dengan versi java.

Ada satu skenario yang Anda tidak pisahkan: jika teknologi Anda akan memungkinkan untuk objek non-tipe khusus dikirim melalui kawat, yaitu, jika Anda dapat menggunakan objek java saat ini sekarang sebagai YAGNI, dan penggantian dengan yang berbeda ketik yang Anda sesuaikan akan berupa drop-in sederhana yang tidak akan merusak apa pun karena mengetik informasi yang masuk kawat. Jadi, pada dasarnya jika informasi jenis tidak melewati batas Anda bisa YAGNI tentang ini.

Hanya berhati-hati dan waspada bahwa setiap upgrade ke versi java Anda tidak mengubah objek-objek ini. Kalau tidak, hanya decouple sekarang dan jangan khawatir tentang hal itu, saya kira itu tergantung pada berapa banyak waktu yang Anda miliki jika Anda punya pilihan.

Namun, jika informasi jenis melewati kawat dalam protokol Anda maka drop-in datar jenis baru ketika perubahan tipe java yang mendasarinya mungkin tidak mungkin dan mungkin lebih merupakan upaya yang lebih besar. Jika itu masalahnya, pergi YAGNI sekarang berarti menambah hutang teknis dan risiko yang terkait dengan teknologi Anda.

Secara pribadi saya hanya akan memisahkan diri sekarang.

Selain itu, KERING tidak berperan dalam hal ini karena Anda tidak menulis bagian yang mendasarinya sehingga Anda tidak menduplikasi kode dan karenanya tidak akan ada rasa sakit bug yang berulang-ulang yang merupakan perhatian utama KERING (dan pemeliharaan umum masalah yang lagi-lagi tidak akan Anda miliki karena Anda tidak memiliki duplikat untuk dipelihara)

Argumen utama untuk # 1 adalah kemudahan implementasi dan peningkatan, tetapi apakah memenuhi persyaratan Anda?

Dalam argumen Anda untuk # 2, Anda mengindikasikan bahwa Java API dan REST API kemungkinan dapat berubah secara independen. Ini berarti mereka adalah masalah yang terpisah dan Anda tidak mengulangi diri Anda dengan menggunakan kelas yang terpisah. Hanya karena dua hal terlihat sama, tidak berarti mereka adalah sama.

API REST Anda tidak harus mengikuti struktur yang sama dengan model data Anda

Saat menerapkan REST, pastikan Anda membuat API eksternal yang intuitif, lalu petakan ini ke kelas model data internal Anda. Ini memungkinkan Anda untuk mengubah satu sama lain secara independen dari yang mengarah ke API yang dapat berlangsung puluhan tahun .

Karena itu, decoupling adalah cara untuk pergi ke sini.