Cara mendukung Versi API yang berbeda

Saya sedang menulis API Istirahat dan saya bertanya-tanya bagaimana cara terbaik untuk menangani mendukung versi yang berbeda. Dengan ini saya tidak bermaksud bagaimana mendefinisikan URI sebagai V2 atau V3, melainkan bagaimana menyusun kode mengingat bahwa itu perlu:

• Mendukung banyak versi secara bersamaan, mis. V1 & V2 & V3 URI harus hidup pada waktu yang bersamaan. Saya akan pensiun V1 ketika mengatakan V4 datang untuk membatasi jumlah yang didukung pada suatu waktu.
• Hindari duplikasi kode sebanyak mungkin
• Buat mudah untuk menambahkan perubahan yang tidak melanggar ke versi, tanpa itu berdampak pada versi lain

Tampaknya ada beberapa pendekatan yang dapat diambil:

• Gunakan Git untuk mengontrol versi, dengan cabang untuk versi yang berbeda (dan versi lama pada dasarnya tidak memiliki pekerjaan pengembangan baru yang dilakukan di atasnya). Ini berarti tidak ada duplikasi kode karena hanya versi terbaru yang ada dalam kode, tetapi versi sebelumnya perlu bekerja dengan versi baru DB sampai mereka pensiun.

• Kode duplikat sehingga setiap versi ditangani dalam aplikasi yang sama dan memiliki jalur kode yang benar-benar terpisah, tetapi ini berarti banyak duplikasi

• Gunakan kembali banyak kode di seluruh versi, tetapi ini akan membuatnya lebih sulit untuk dipertahankan karena mengubah satu versi lebih mungkin berdampak pada versi sebelumnya

Apakah ada praktik terbaik untuk mengatasi masalah ini karena semua opsi tampaknya memiliki masalah sendiri?

Melakukan hal ini:

Gunakan kembali banyak kode di seluruh versi, tetapi ini akan membuatnya lebih sulit untuk dipertahankan karena mengubah satu versi lebih mungkin berdampak pada versi sebelumnya

tapi jangan merusak versi sebelumnya.

Anda harus memiliki tes yang memverifikasi bahwa semua versi yang didukung berfungsi dengan benar. Jika Anda tidak memiliki tes tersebut, maka Anda harus membuatnya terlebih dahulu untuk mencakup kode apa pun yang Anda ubah.

Kombinasi menggunakan cabang rilis GIT (atau bercabang setiap versi ke repositori terpisah) untuk mendukung dan memelihara versi API lama dan mungkin memiliki beberapa kode yang dapat digunakan kembali yang dapat dibagikan sebagai ketergantungan, seperti perpustakaan umum, kemungkinan besar adalah cara untuk pergi. Jadi setiap versi API akan menjadi artefak yang dapat digunakan secara terpisah. Ini memungkinkan fleksibilitas sehingga, misalnya, API V1 dapat bergantung pada commons V1, sementara API V2, V3, V4 dapat bergantung pada comm2 V2. Ini akan menjadi yang termudah dan terbersih dari perspektif pengembangan karena basis kode Anda tidak berlipat ganda dengan setiap versi baru, sebaliknya setiap versi diisolasi ke dalam proyek / basis kode itu sendiri dan hanya mementingkan dirinya sendiri.

Alasan lain untuk menggunakan artefak terpisah adalah bahwa mungkin ada masalah lintas sektoral seperti mekanisme keamanan, atau kerangka kerja / pustaka seperti kerangka injeksi ketergantungan Anda yang dapat berubah dalam versi API yang lebih baru dan akan membuat banyak kesulitan dalam mendukung API yang lebih lama jika mereka semua hidup dalam basis kode yang sama (dan Classloader saat runtime, jika itu Java).

Setiap pendekatan, apakah itu cabang per versi atau basis kode duplikat monolitik, akan selalu memiliki masalah titik integrasi umum (seperti DB, atau skema cache terdistribusi) yang perlu diubah. API versi yang lebih lama mungkin memerlukan beberapa jenis pemeliharaan untuk bekerja dengan perubahan itu, atau pengenalan beberapa alat lain (seperti tampilan basis data) untuk membantu kompatibilitas. Ini mungkin kesulitan yang tidak dapat dihindari tergantung pada sifat perubahan Anda.

Saya tidak tahu seberapa berbedanya hasil dari versi API Anda, tetapi Anda bisa memiliki lapisan kompatibilitas di tengah yang dapat beralih di antara versi dan mengisi celah atau menerjemahkan data.

Yang sedang dikatakan - biasanya tidak pernah berhasil satu-ke-satu - jadi sakelar atau desain tipe mesin negara telah membantu saya dengan masalah ini.