Bagaimana cara menggambarkan perubahan arsitektur yang sengaja melanggar standar REST?

Saya mengusulkan perubahan pada proyek perangkat lunak yang dirancang dengan buruk yang mengalami banyak masalah. Pada tingkat tinggi, proyek ini menggunakan Angular di front-end dan menggunakan berbagai API REST; itu semua hebat (saya tidak melihat perlunya mengubah teknologi atau alat kami). Masalahnya adalah bahwa basis kode secara proporsional lebih besar di UI daripada API sisi server. Sebagian besar logika bisnis tinggal di UI, dengan REST API menjadi antarmuka basis data CRUD sederhana ke lapisan UI.

Misalnya, POST ke pelanggan akan membuat catatan pelanggan, sementara PUT akan mengubah pelanggan itu. Tidak lebih, dan tidak sedikit. Namun logika bisnis kami lebih menuntut dari itu. Proses umum menciptakan pelanggan tidak lebih dari memasukkan 1 catatan basis data. Ini akan menyediakan data dalam tabel lain yang diperlukan, melakukan validasi dan perhitungan tertentu, dll. Saya lebih suka untuk membuat panggilan POST / PUT tunggal yang merangkum semua perilaku ini, meringankan beban klien yang mengonsumsi.

Jadi sudut pandang saya adalah orkestrasi menyeluruh ini harus hidup di server (di mana kami memiliki kontrol penuh, log, dll), bukan UI, tetapi satu argumen berlawanan adalah bahwa pendekatan ini tidak lagi tenang. Jadi saya tidak yakin bagaimana cara terbaik menggambarkan pendekatan ini ketika rekomendasi saya adalah untuk melanjutkan dengan tumpukan teknologi yang ada, tetapi menerapkan perubahan mendasar di lokasi di mana kode berada.

Saya tidak yakin bagaimana cara terbaik menggambarkan pendekatan ini ketika rekomendasi saya adalah untuk melanjutkan dengan tumpukan teknologi yang ada, tetapi menerapkan perubahan mendasar di lokasi di mana kode berada.

Service oriented architecture.

Anda mengusulkan untuk mendesain ulang sistem Anda sehingga aturan bisnis dan data Anda berada di tempat yang sama. Itu secara efektif definisi layanan ; lihat pembicaraan Udi Dahan tentang Menemukan Batas Layanan .

Bilah samping: seperti dicatat oleh Eric, ini tidak ada hubungannya dengan "REST". Sama sekali tidak ada alasan bahwa Anda tidak dapat menempatkan REST API (artinya, API yang memenuhi batasan gaya arsitektur REST ) di depan layanan Anda. Tapi itu mungkin tidak jelas bagi orang-orang yang mengerti REST berarti pemetaan operasi basis data dengan metode HTTP.

Mungkin, atau mungkin tidak, layak untuk berinvestasi dalam mengubah pemahaman audiens Anda tentang REST.

REST bukan CRUD. "Tandingan" itu didasarkan pada pemahaman yang cacat secara fundamental tentang apa itu REST. Saya belum melihat apa pun di pos Anda yang menunjukkan bahwa perubahan Anda akan membuat API Anda lebih atau kurang TETAP.

Satu hal lagi yang perlu diingat adalah sebagai berikut ... Tidak memvalidasi sisi server aturan bisnis Anda, berarti Anda secara implisit memercayai apa pun yang masuk, melalui katakanlah permintaan POST, valid.

Artinya, misalnya, sementara aplikasi sudut Anda mungkin memeriksa apakah pelanggan memiliki rentang usia yang valid dan memastikan bahwa pengguna yang sah mendapatkan umpan balik yang benar, siapa pun yang mengetahui url ke api Anda dapat melakukan permintaan POST yang berisi beberapa nilai tidak sah yang akan tidak lagi divalidasi.

Jadi saran saya adalah memindahkan aturan bisnis Anda ke API, membiarkannya memvalidasi input dan mengembalikan kesalahan yang sesuai (atau mungkin hanya kode yang menunjukkan apa yang salah) di badan respons. Kode-kode itu kemudian dapat digunakan oleh aplikasi front-end Anda untuk menunjukkan apa yang salah.

Untuk menambah jawaban baik lainnya di sini:

Antarmuka Anda, REST atau sebaliknya, tidak boleh dibatasi berdasarkan semacam asumsi seputar detail implementasi. Ini sepenuhnya bertentangan dengan gagasan layanan sebagai lapisan abstraksi.

Salah satu manfaat utama menggunakan layanan adalah detail implementasi dapat diubah tanpa klien harus melakukan apa pun. Dari apa yang telah Anda jelaskan, sepertinya tidak ada lapisan abstraksi nyata. Detail implementasi telah diekspos melalui HTTP. Tidak ada apapun tentang REST yang perlu, membantu, atau diinginkan. Bahkan, saya pikir saya bisa berdebat bagian-bagian tertentu dari definisi REST berarti bahwa ini sebenarnya, implementasi non-TENANG.

Apa yang Anda sarankan adalah bagaimana lapisan layanan yang tepat harus dirancang. Jika seseorang mengatakan kepada Anda bahwa Anda tidak dapat melakukannya karena itu tidak tenang, itu disayangkan. Anda dapat yakin bahwa seseorang yang memberi tahu Anda yang tidak tahu banyak tentang REST.

Berdasarkan pertanyaan Anda, Anda memiliki sumber daya yang disebut pelanggan. Apa pun dan segala sesuatu yang diperlukan untuk membuat sumber daya pelanggan yang valid dapat dan harus ditangani dalamPOST ke sumber daya basis pelanggan (atau secara bergantian / opsional dalam PUT ke sumber daya pelanggan tertentu, jika tidak ada.) REST tidak mengatakan apa-apa tentang berapa banyak catatan basis data yang perlu Anda buat pada panggilan yang diberikan. Seperti komentar Colin Young, tidak perlu ada database sama sekali, itu sama sekali tidak relevan bagaimana layanan diimplementasikan dari perspektif REST.

Ada beberapa jawaban bagus di sini, tetapi saya tidak yakin mereka akan membantu Anda meyakinkan rekan kerja Anda. Seperti yang telah ditunjukkan oleh banyak orang, apa yang Anda sarankan bukanlah bergeser dari desain RESTful, dan saya pikir itu adalah kunci untuk membuatnya sesuai dengan proposal Anda.

REST bukan tentang memastikan API Anda hanya memungkinkan menyimpan dan mengambil data. Sebaliknya, ini berkaitan dengan tindakan pemodelan sebagai sumber daya. API Anda harus mengaktifkan tindakan yang harus diambil (bagaimanapun, ini adalah Antarmuka Pemrograman Aplikasi ). Pertanyaannya adalah bagaimana memodelkan tindakan tersebut.

Daripada menggunakan istilah, contoh mungkin adalah cara terbaik untuk menjelaskan hal ini kepada rekan kerja Anda . Dengan cara ini Anda dapat menunjukkan bagaimana mereka melakukannya sekarang, masalah apa yang menyebabkannya, solusi yang memecahkan masalah, dan bagaimana itu masih TETAP.

Mari kita lihat objek Pelanggan Anda.

Masalah:

UI POST Pelanggan, tetapi tabel selanjutnya belum diperbarui. Bagaimana jika salah satu dari panggilan berikutnya gagal karena kesalahan pada kode UI Anda (atau plugin browser yang tidak sesuai, dll)? Sekarang data Anda dalam keadaan tidak konsisten. Bahkan bisa berupa keadaan yang memecah bagian lain dari API atau UI Anda, belum lagi itu hanya tidak valid. Bagaimana Anda pulih? Anda harus menguji untuk setiap keadaan yang memungkinkan untuk memastikan ini tidak akan merusak sesuatu, tetapi akan sulit untuk mengetahui apa yang mungkin.

Larutan:

Buat titik akhir API untuk membuat pelanggan. Anda tahu Anda tidak ingin memiliki titik akhir "/ pelanggan / buat" atau bahkan "/ buat-pelanggan", karena buat adalah kata kerja dan akan melanggar REST. Jadi kata benda itu. "/ penciptaan pelanggan" bisa berhasil. Sekarang ketika Anda POST objek CustomerCreation Anda, itu akan mengirim semua bidang yang diperlukan untuk pelanggan dibuat sepenuhnya. Titik akhir akan memastikan bahwa data lengkap dan valid (mengembalikan 400 atau sesuatu jika gagal validasi), dan dapat bertahan semua dalam transaksi db tunggal, misalnya.

Jika Anda juga membutuhkan titik akhir untuk MENDAPATKAN / objek pelanggan, itu bagus. Anda dapat memiliki keduanya. Caranya adalah dengan menciptakan titik akhir yang melayani kebutuhan konsumen.

Keuntungan:

1. Anda menjamin bahwa Anda tidak akan berakhir dengan keadaan buruk
2. Ini sebenarnya lebih mudah di devs UI jika mereka tidak harus "tahu" memesan permintaan, masalah validasi, dll
3. Itu tidak seperti mengobrol tentang API, mengurangi latensi permintaan jaringan
4. Lebih mudah untuk menguji dan membuat konsep skenario (potongan data yang hilang / cacat dari UI tidak tersebar di seluruh permintaan, beberapa di antaranya mungkin gagal)
5. Ini memungkinkan enkapsulasi logika bisnis yang lebih baik
6. Secara umum membuat keamanan lebih mudah (karena logika bisnis dan orkestrasi di UI dapat dimodifikasi oleh pengguna)
7. Kemungkinan akan mengurangi duplikasi logika (lebih besar kemungkinan Anda akan memiliki 2+ konsumen suatu API daripada 2+ API yang memberikan akses ke data yang sama)
8. Masih 100% tenang

Kekurangan:

1. Ini berpotensi lebih banyak pekerjaan untuk dev backend (tetapi mungkin tidak dalam jangka panjang)

Mungkin sulit bagi orang untuk memahami paradigma ini dan apa gunanya jika mereka belum mencobanya. Semoga Anda dapat membantu mereka melihat dengan menggunakan contoh dari kode Anda sendiri.

Pengalaman saya sendiri adalah begitu para devs di tim saya mulai menerapkan strategi ini, mereka segera melihat manfaatnya.

Pelajaran lanjutan:

Artikel ini dari pemikiran benar-benar membantu saya mendapatkan ide pemodelan tindakan sebagai objek menggunakan contoh-contoh praktis: https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling

Saya juga menyarankan membaca tentang CQRS dan Event Sourcing karena mereka berkaitan dengan hal-hal semacam ini (yaitu menceraikan API Anda dari logika kegigihan yang sebenarnya). Saya tidak tahu seberapa besar keinginan rekan kerja Anda untuk membaca hal semacam ini, tetapi hal itu dapat memberi Anda lebih banyak kejelasan dan membantu Anda menjelaskannya kepada mereka.