Haruskah orang umumnya mengembangkan perpustakaan klien untuk layanan REST untuk membantu mencegah kerusakan API?

Kami memiliki proyek di mana kode UI akan dikembangkan oleh tim yang sama tetapi dalam bahasa yang berbeda (Python / Django) dari lapisan layanan (REST / Java). Kode untuk setiap lapisan keluar dalam repositori kode yang berbeda dan yang dapat mengikuti siklus rilis yang berbeda. Saya mencoba untuk datang dengan proses yang akan mencegah / mengurangi kerusakan pada lapisan layanan dari perspektif lapisan UI.

Saya berpikir untuk menulis tes integrasi pada tingkat lapisan UI yang akan kita jalankan setiap kali kita membangun lapisan UI atau layanan (kita menggunakan Jenkins sebagai alat CI kami untuk membangun kode yang ada dalam dua repositori Git) dan jika ada kegagalan maka sesuatu di lapisan layanan rusak dan komit tidak diterima.

Apakah itu juga merupakan ide yang baik (apakah ini merupakan praktik terbaik?) Untuk membuat pengembang lapisan layanan membuat dan memelihara perpustakaan klien untuk layanan REST yang ada di lapisan UI yang akan mereka perbarui setiap kali ada perubahan pada API Layanan mereka? Dapat dibayangkan, kita kemudian akan mendapat keuntungan dari API yang diketik secara statis yang dibangun oleh kode UI. Jika pustaka klien perubahan API, maka kode UI tidak akan dikompilasi (jadi kami akan segera tahu bahwa ada perubahan yang melanggar). Saya juga masih menjalankan tes integrasi setelah membangun UI atau lapisan layanan untuk lebih memvalidasi bahwa integrasi antara UI dan layanan masih berfungsi.

Secara umum, untuk metode API yang hilang, pilih satu konvensi dan 'hilangkan' mereka, terutama segera setelah penuh, API pengganti tersedia dan diuji. Biarkan API lama tetap di tempatnya (intinya), tetapi beri tag metadata tanda tangan metode atau masukkan peristiwa logging sehingga penggunaan dapat diidentifikasi dengan jelas.

Masuk dalam API layanan adalah satu hal, tetapi memberi tahu klien yang mengonsumsi adalah hal lain. Untuk REST, saya rasa tidak ada praktik standar yang solid. Klien FourSquare API dapat menemukan metode yang dihentikan bahkan jika metode yang disebut berhasil (kode HTTP 200, namun errorType akan diatur ke 'usang'). Mungkin strategi yang masuk akal untuk menyediakan klien dengan kesempatan untuk pengetahuan tentang metode yang sudah usang dalam API tanpa menyebabkan kerusakan.

https://developer.foursquare.com/overview/responses

Dalam panduan API Anda, sarankan tanggal atau bangun nomor rilis tempat API yang sudah tidak digunakan lagi akan dihapus sepenuhnya. Ketika Anda menyempurnakan strategi kami untuk penghentian, Anda akan ingin memberi tahu konsumen API tentang apa strategi yang diusulkan (bagaimana mereka dapat menemukan metode yang sudah usang, bagaimana beralih ke API pengganti, dan ketika API yang sudah tidak digunakan lagi tidak akan tersedia jika dibersihkan selama pembersihan API), dan mintalah umpan balik dari mereka untuk memastikan prosesnya adalah buatan untuk semua orang.

Membuat versi API Anda adalah kemungkinan lain. Saat versi baru digunakan, biarkan versi lama juga aktif dan biarkan negosiasi melalui permintaan. Jika Anda mempertahankan versi 2 atau 3 terbaru, maka kode UI dapat memutakhirkan dengan kecepatannya sendiri.

Setidaknya ada tiga pertanyaan sekaligus, mari kita lakukan satu per satu

• "Apakah ide yang bagus untuk memiliki perpustakaan klien untuk layanan REST?"

Kemungkinan besar ya, selama Anda tidak ingin panggilan REST sewenang-wenang langsung tersebar melalui semua kode UI Anda.

• "Apakah ide yang bagus untuk membiarkan pengembang lapisan layanan membuat dan memelihara lib?"

Itu tergantung pada orang-orang di tim Anda. Pemelihara API harus mengetahui keduanya, hal-hal yang tersedia di lapisan layanan serta persyaratan lapisan UI. Jadi dapat berupa orang dari lapisan layanan atau satu dari lapisan UI, atau (tergantung pada ukuran dan tugas lainnya) seseorang secara independen dari kedua tim.

• [akankah kita mendapatkan keuntungan dari fakta bahwa] "jika API perpustakaan klien berubah, maka kode UI tidak akan dikompilasi"

Bukankah Anda mengatakan UI akan ditulis dengan Python? Itu bukan bahasa yang diketik secara statis, jadi saya tidak akan mengharapkan build build segera dari perubahan API. Saya berasumsi saya salah pada saat ini dan Anda memiliki API yang diketik secara statis di sini - maka Anda mungkin mendapatkan beberapa keuntungan di sini selama build tidak rusak ketika hanya menambahkan beberapa fitur baru (seperti parameter opsional baru) ke API. Kalau tidak, Anda akan menghasilkan banyak overhead yang tidak perlu untuk tim Anda.