REST API vs panggilan DB langsung di Aplikasi Desktop

Saat ini saya merencanakan aplikasi yang akan digunakan di perusahaan. Diperlukan untuk membangun Aplikasi Desktop. Saat ini mereka tidak yakin apakah aplikasi tersebut akan tersedia di ponsel atau browser dalam waktu dekat.

Saya memiliki dua kemungkinan:

Akses database secara langsung dari Aplikasi Desktop
Buat REST API dan sambungkan ke ini

Bisakah saya menggunakan API REST jika aplikasi tetap hanya Aplikasi Desktop dalam perusahaan? Saya tahu itu mungkin, tetapi apakah itu "benar"? (Praktik terbaik)

Ada beberapa (mungkin) keuntungan dan kerugian untuk membuat secara langsung API REST:

Kekurangan:

Butuh waktu lebih lama untuk berkembang
Lebih kompleks
Server bekerja lebih banyak
̶Se̶̶c̶̶u̶̶r̶̶i̶̶t̶̶y̶̶ ̶̶i̶̶s̶̶s̶̶u̶̶e̶̶s̶̶? ̶
Lebih lambat? (Server dan Aplikasi Desktop berada di Jaringan yang sama)

Keuntungan:

Bermigrasi ke platform lain lebih mudah
Logika Bisnis juga diperlukan saat memanggil langsung basis data. Tidak akan butuh waktu lebih lama untuk berkembang
Hal yang sama berlaku untuk kompleksitas
Keamanan (sebagaimana disebutkan oleh tkausl dalam komentar)
Maintainability (seperti yang disebutkan oleh WindRaven dalam komentar)

— devz
sumber

Anda benar-benar dianggap Security issuessebagai kerugian untuk REST-API?

— tkausl

Saya dapat melindungi API saya dengan misalnya OAuth2 dan TLS, tetapi ini akan menambah lebih banyak pekerjaan. Saya tidak tahu seberapa aman panggilan DB langsung. Misalnya dengan JPA. Itu sebabnya saya menambahkan tanda tanya karena saya tidak begitu yakin.

— devz

Yah, Anda tidak bisa mendapatkan keamanan yang lebih rendah daripada panggilan db langsung, kecuali Anda memberikan login root.

— tkausl

Keuntungan lain, perubahan logika bisnis hanya perlu dilakukan pada REST API dan disebarkan ke server, tidak dibuat dan kemudian setiap klien diperbarui. (asalkan antarmuka API tidak berubah sebagai hasilnya)

— RubberChickenLeader

Apakah basis data berjalan pada komputer yang sama dengan aplikasi? Jika tidak, saya bahkan tidak akan berpikir tentang akses tulis langsung ke database.

— CodesInChaos

Jawaban:

Ketika datang ke aplikasi besar dengan database besar yang berisi jutaan catatan, Anda segera menyadari, memilih, memperbarui, menyisipkan, dan menghapus sama sekali tidak cukup.

Jadi Anda mulai berpikir dengan cara yang berbeda. Anda membuat prosedur dan pemicu untuk menangani hal-hal yang lebih rumit secara langsung dalam database dan ini tidak terlalu baik. Database menawarkan kinerja hebat saat melakukan operasi CRUD. Prosedur yang panjang? Tidak terlalu banyak.

Masalah dengan prosedur

Sekarang bayangkan, bahwa Anda beralih ke database yang tidak mendukung konsep prosedur? Apa yang akan kamu lakukan? Anda terpaksa memindahkan prosedur ke basis kode Anda, di mana Anda dapat yakin bahwa sekali Anda memprogram di katakanlah Java, itu akan selalu tetap di sana, tidak peduli mesin database mana yang Anda pilih.

Belum lagi, prosedur Anda biasanya merupakan bagian dari logika bisnis Anda dan itu bukan ide yang baik untuk memiliki logika bisnis Anda terpecah di basis kode dan basis data Anda.

Idealnya, Anda harus selalu memiliki mediator antara database dan klien yang menerapkan aturan bisnisnya sendiri. Menyediakan akses langsung ke database bukanlah ide yang baik, karena ketika Anda melakukannya, orang yang memiliki akses memiliki akses langsung ke tabel dan dapat melakukan hampir semua hal dengan data yang ada.

Kekurangan

Perlu waktu lebih lama untuk berkembang: Tentu saja, Anda membuat sistem baru, yang akan lebih memakan waktu daripada sekadar memberi klien string koneksi basis data dan membiarkannya menulis kueri.
Lebih kompleks: Kompleksitas suatu sistem> kompleksitas kueri basis data.
Server bekerja lebih banyak: Tidak harus. Dengan desain yang baik, caching, ... Anda dapat memindahkan beban dari server database ke salah satu mediator.
Lebih lambat: Dalam hal pengembangan? Iya. Dalam hal kecepatan saat mengambil data? Tidak. Anda dapat mengoptimalkan mediator Anda menggunakan cache (seperti - populer pada Januari 2016 - Redis, Elasticsearch) dan benar-benar membuatnya mengirimkan data lebih cepat daripada permintaan basis data biasa.

Keuntungan

Memigrasi ke platform lain lebih mudah: Bermigrasi ke mesin database baru? Pastinya. Memigrasi seluruh mediator ke bahasa baru? Tidak juga.
Logika Bisnis juga diperlukan saat memanggil langsung basis data. Tidak akan butuh waktu lebih lama untuk berkembang: Seperti dijelaskan sebelumnya, masalah prosedur.
Keamanan: Dengan otorisasi yang tepat memiliki mediator jelas jauh lebih aman daripada memberi pengguna akses langsung ke database, karena Anda membatasi dia pada titik akhir yang hanya menjalankan kueri yang Anda inginkan.
Maintainability: Salah satu manfaat terbaik dari memiliki seorang mediator. Jika ada bug dalam API yang dipanggil klien Anda, Anda memperbaikinya, mendorong perbaikan ke repositori VCS Anda, membangun mediator Anda dari versi arus VCS yang berisi perbaikan dan semua klien Anda tiba-tiba menggunakan perbaikan, tanpa mereka perlu unduh pembaruan. Ini tidak mungkin dilakukan, jika kueri disimpan langsung di aplikasi klien. Dalam hal ini, klien dipaksa untuk memperbarui aplikasi mereka.

— Andy
sumber

Seberapa sering Anda menghadapi tantangan beralih ke database yang tidak mendukung konsep prosedur ketika Anda benar-benar menggunakannya?

— harpun

@harpun Dua kali dalam 2 tahun terakhir. Ketika saya dan tim saya bekerja dengan sebuah proyek memutuskan untuk pergi dari MySQL atau PostgreSQL ke MongoDB sebagai bagian untuk beralih ke Node.js dan juga untuk menghindari kunci mati dan menyimpan objek sebagai agregat secara langsung.

— Andy

Ada pilihan lain selain akses langsung ke db. "API mediator" tidak harus menggunakan HTTP, karenanya server HTTP tidak harus terlibat sama sekali. Ini bisa berupa API tingkat kode. Pertanyaan lain adalah, asalkan Anda tidak puas dengan kecepatan bahasa pemrograman Anda, apakah akan ada API (akses REST) yang ditulis dengan beberapa bahasa / platform lain dari logika bisnis Anda ...

— forsberg

Inilah pendapat saya tentang masalah ini: Anda memiliki gagasan yang tepat tentang keinginan untuk menggunakan layanan web, tetapi Anda mungkin berencana menggunakan teknologi yang salah.

Ketika Anda mengatakan REST, saya berasumsi Anda sedang berbicara tentang Asp.Net WebApi. Itu teknologi yang salah untuk aplikasi intranet. REST & WebApi luar biasa, jangan salah paham, tetapi untuk aplikasi internal apa pun, layanan web WCF adalah cara untuk menurut hemat saya. Mereka memungkinkan klien untuk merujuk titik akhir layanan seperti perpustakaan kelas, yang berarti Anda tidak berurusan dengan XML atau JSON di klien desktop Anda. Anda bekerja dengan kelas & objek.

Bagaimanapun, ya. Anda punya ide yang tepat. Jika mereka tidak yakin apakah mereka akan membutuhkan klien berbasis web, maka Anda harus membuat arsitek sistem Anda untuk dengan mudah menambahkannya jika mereka memutuskan mereka menginginkannya nanti. Jauh lebih mudah untuk menambahkan berbagai jenis klien ketika Anda memiliki arsitektur berorientasi layanan.

— Bebek karet
sumber

Sangat bodoh untuk menggunakan klien untuk membatalkan deserialize json ke objek. Kelas-kelas bahkan dapat dihasilkan secara otomatis dari example json dengan menggunakan json2csharp.com . Ia bekerja dengan baik dengan klien http dari paket nuget microsoft.aspnet.webapi.client. Anda kembali ke tanah objek lebih cepat daripada berurusan dengan referensi klien WCF yang saya janjikan, jadi ini seharusnya tidak menjadi pendorong utama untuk memilih WCF.

— Esben Skov Pedersen

@EsbenSkovPedersen ada perbedaan antara bodoh mudah dan otomatis .

— RubberDuck

Karena tidak pernah ada masalah dengan WCF? Itu tidak benar.

— Esben Skov Pedersen

Siapa yang pernah mengatakan tidak ada masalah dengan WCF @EsbenSkovPedersen? Saya yakin tidak. Setiap teknologi memiliki masalah. Apa masalahmu?

— RubberDuck

Ketika Anda mengatakan itu lebih mudah daripada bodohnya mudah Anda menyiratkan itu. Saya tidak punya masalah.

— Esben Skov Pedersen

Lihatlah dengan cara ini, itu jelas merupakan pola umum dan mungkin bisa digambarkan sebagai praktik terbaik.

Bergantung pada platform Anda, Anda mungkin menemukan alat yang hampir membuat masalah hilang - Microsoft memiliki dukungan ODATA untuk aplikasi terhubung yang seharusnya membuat formulir di atas data secara langsung begitu Anda telah menaiki kurva belajar.

Lebih pragmatis - mendefinisikan API yang Anda butuhkan untuk lapisan data Anda di aplikasi desktop dan kode untuk API itu. Letakkan semua akses basis data di belakang API itu - yang sebenarnya membuat segalanya lebih baik dari perspektif pengembangan aplikasi - dan kemudian lokasi kode akses basis data yang sebenarnya menjadi kurang signifikan (API yang sama dapat diimplementasikan oleh kode yang berbicara langsung ke basis data atau dengan kode yang berbicara secara tidak langsung ke database melalui titik akhir istirahat). Jika Anda mulai dengan implementasi langsung maka versi REST secara substansial akan menjadi pembungkus putaran API yang sama sehingga Anda tidak akan dihukum terlalu buruk ...

Ini mungkin tidak sesederhana yang saya inginkan - tetapi ini adalah pola yang baik, ini memberi Anda fleksibilitas yang mungkin Anda butuhkan tanpa pergi jauh ke jalur YAGNI .

— Murph
sumber