Haruskah Anda menulis back-end Anda sebagai API?

Saya melakukan diskusi hangat hari ini tentang aplikasi MVC kami. Kami memiliki situs web yang ditulis dalam MVC ( ASP.NET ), dan biasanya mengikuti pola melakukan sesuatu dalam tampilan -> tekan controller -> controller membangun model (memanggil Manajer yang mendapatkan data, membangun model dalam metode controller itu sendiri) -> model pergi untuk melihat -> bilas & ulangi.

Dia mengatakan bahwa kode kita terlalu erat. Misalnya, jika kami menginginkan aplikasi desktop juga, kami tidak akan dapat menggunakan kode yang ada.

Solusi dan praktik terbaik yang dia katakan adalah membangun API, dan kemudian membangun situs web Anda di atas API Anda, dan kemudian membangun aplikasi desktop, aplikasi seluler, dll. Sangat sederhana.

Ini sepertinya ide yang buruk bagi saya karena berbagai alasan.

Pokoknya saya tidak dapat menemukan apa pun dengan googling yang mungkin membahas praktik ini. Apakah ada yang punya informasi tentang pro, kontra, mengapa Anda harus, mengapa Anda tidak harus atau membaca lebih lanjut?

Beberapa alasan saya pikir itu ide yang buruk:

• Terlalu abstrak untuk menjalankan backend Anda dari API. Anda mencoba membuatnya terlalu fleksibel yang akan membuatnya berantakan.

• Semua hal yang dibangun dalam MVC tampaknya tidak berguna, seperti peran dan otentikasi. Misalnya, atribut [Keamanan] dan keamanan; Anda harus menggulung sendiri.

• Semua panggilan API Anda akan memerlukan informasi keamanan terlampir, dan Anda harus mengembangkan sistem token dan yang lainnya.

• Anda harus menulis panggilan API lengkap untuk setiap fungsi yang akan dilakukan program Anda. Hampir setiap metode yang ingin Anda implementasikan harus dijalankan dari API. Dapatkan / Perbarui / Hapus untuk setiap pengguna, plus varian untuk setiap operasi lainnya, misalnya perbarui nama pengguna, tambahkan pengguna ke grup, dll. Dll. Dan masing-masing akan menjadi panggilan API yang berbeda.

• Anda kehilangan semua jenis alat seperti antarmuka dan kelas abstrak ketika datang ke API. Hal-hal seperti WCF memiliki dukungan yang sangat lemah untuk antarmuka.

• Anda memiliki metode yang menciptakan pengguna, atau melakukan beberapa tugas. Jika Anda ingin membuat 50 pengguna, Anda bisa menyebutnya 50 kali. Ketika Anda memutuskan untuk melakukan metode ini sebagai API, server web Anda dapat menamainya dengan pipa bernama dan tidak ada masalah - klien desktop Anda juga dapat melakukannya, tetapi tiba-tiba kreasi pengguna massal Anda akan melibatkan pemalu API melalui Internet 50 kali yang tidak bagus Jadi Anda harus membuat metode massal, tetapi sebenarnya Anda hanya membuatnya untuk klien desktop. Dengan cara ini, Anda pada akhirnya harus a) memodifikasi API Anda berdasarkan apa yang diintegrasikan dengannya, dan Anda tidak bisa langsung berintegrasi dengannya, b) melakukan lebih banyak pekerjaan untuk membuat fungsi tambahan.

• YAGNI . Kecuali jika Anda secara khusus berencana untuk menulis dua aplikasi yang berfungsi identik, satu web dan satu aplikasi Windows misalnya, itu adalah sejumlah besar pekerjaan pengembangan tambahan.

• Debugging jauh lebih sulit ketika Anda tidak dapat melangkah dari ujung ke ujung.

• Banyak operasi independen yang akan membutuhkan banyak bolak-balik, misalnya beberapa kode mungkin mendapatkan pengguna saat ini, periksa pengguna di peran administrator, dapatkan perusahaan milik pengguna, dapatkan daftar anggota lain, kirim semua anggota email. Itu akan membutuhkan banyak panggilan API, atau menulis metode khusus tugas khusus yang Anda inginkan, di mana satu-satunya manfaat metode dipesan lebih dahulu adalah kecepatan, tetapi downside akan menjadi tidak fleksibel.

• Mungkin beberapa alasan lagi ini hanya di luar kepala saya.

Sepertinya saya suka kecuali Anda benar-benar membutuhkan dua aplikasi yang identik, maka itu benar-benar tidak layak. Saya belum pernah melihat aplikasi ASP.NET yang dibangun seperti ini juga, Anda harus menulis dua aplikasi terpisah (API dan kode Anda) dan versi mengontrol keduanya juga (jika halaman pengguna Anda mendapatkan bidang baru, Anda harus Anda harus memperbarui API dan kode konsumsi Anda secara bersamaan untuk memastikan tidak ada efek buruk atau membuat banyak pekerjaan tambahan agar tetap kuat).

Sunting: Beberapa tanggapan hebat, benar-benar mulai mendapatkan ide bagus tentang apa artinya semua ini sekarang. Jadi untuk memperluas pertanyaan saya, bagaimana Anda menyusun aplikasi MVC untuk mengikuti struktur API ini?

Misalnya, Anda memiliki situs web yang menampilkan info tentang pengguna. Di bawah MVC, Anda memiliki:

Lihat - (CS) halaman HTML yang menampilkan Pengontrol UserViewModel - Memanggil GetUser () dan membuat UserViewModel yang diteruskan ke kelas Manajer tampilan (semacam API Anda) yang memiliki metode GetUser.

Pengontrol tidak GetUser () tetapi Anda ingin aplikasi desktop juga. Ini artinya GetUser Anda perlu diekspos melalui semacam API. Anda mungkin menginginkan koneksi TCP, baik WCF, atau mungkin Remoting. Anda juga menginginkan aplikasi seluler yang akan tenang karena koneksi yang terus-menerus tidak stabil.

Jadi, bisakah Anda menulis API untuk masing-masing, layanan web WCF yang memiliki metode GetUser () dan kodenya begitu return new UserManager().GetUser()? Dan metode web api mvc 4 yang melakukan hal yang sama? Sambil terus memanggil GetUser secara langsung dalam metode pengontrol MVC Anda?

Atau apakah Anda memilih solusi yang akan bekerja untuk ketiganya (layanan web api REST) ​​dan membangun semuanya berdasarkan itu, sehingga ketiga aplikasi melakukan panggilan API (yang mvc, ke mesin lokal).

Dan apakah ini hanya skenario teoretis yang sempurna? Saya dapat melihat overhead besar dalam mengembangkan cara ini, terutama jika Anda harus mengembangkan dengan cara yang akan memungkinkan Anda melakukan operasi dengan tenang. Saya pikir beberapa di antaranya telah tercakup dalam balasan.

Sunting 2: Setelah membaca lebih banyak hal, saya telah memberikan komentar di bawah ini yang saya pikir dapat menjelaskannya. Pertanyaannya adalah sedikit pertanyaan jebakan, saya pikir. Jika Anda menulis back-end Anda sebagai API membuat saya bingung berpikir harus ada satu layanan web yang semuanya (panggilan mvc, aplikasi desktop, aplikasi seluler) panggilan untuk melakukan hal-hal.

Kesimpulan yang saya dapatkan adalah bahwa apa yang harus Anda lakukan adalah memastikan bahwa lapisan logika bisnis Anda dipisahkan dengan benar. Melihat kode saya, saya sudah melakukan ini - controller akan memanggil GetUser()manajer, lalu membuat model tampilan dari itu untuk membuat dengan Tampilan. Jadi sungguh, lapisan logika bisnis adalah API. Jika Anda ingin memanggilnya dari aplikasi desktop, Anda harus menulis sesuatu seperti layanan WCF untuk memudahkan memanggilnya. Bahkan hanya memiliki metode WCF yang disebut GetUser()yang berisi kode return MyBusinessLayer.GetUser()akan cukup. Jadi API adalah logika bisnis, dan WCF / web api dll hanyalah titlits kode untuk membiarkan aplikasi eksternal memanggilnya.

Jadi ada beberapa overhead, di mana Anda harus membungkus lapisan logika bisnis Anda dalam API yang berbeda tergantung pada apa yang Anda butuhkan, dan Anda harus menulis metode API untuk setiap operasi yang Anda ingin aplikasi lain lakukan, ditambah Anda harus memilah cara untuk melakukan otentikasi, tetapi sebagian besar sama. Tempelkan logika bisnis Anda di proyek yang terpisah (perpustakaan kelas), dan Anda mungkin tidak akan mengalami masalah!

Semoga interpretasi ini benar. Terima kasih atas semua diskusi / komentar yang telah dihasilkannya.

Ya kamu harus.

Ini tidak hanya membuat bagian belakang Anda dapat digunakan kembali tetapi memungkinkan untuk keamanan yang lebih dan desain yang lebih baik. Jika Anda menulis backend Anda sebagai bagian dari sistem tunggal, Anda membuat desain monolitik yang tidak pernah mudah untuk diperluas, diganti atau ditingkatkan.

Salah satu area di mana ini populer saat ini adalah di Microservices . Di mana backend dipecah menjadi banyak layanan kecil (atau bahkan besar) yang masing-masing menyediakan API yang dikonsumsi oleh sistem klien. Jika Anda membayangkan menggunakan banyak sumber data pihak ketiga dalam aplikasi Anda, Anda sadar bahwa Anda mungkin sudah melakukan ini.

Satu manfaat lainnya adalah bahwa konstruksi dan pemeliharaan setiap layanan dapat diserahkan ke tim yang berbeda, mereka dapat menambahkan fitur yang tidak mempengaruhi tim lain yang menghasilkan produk. Hanya ketika mereka selesai dan merilis layanan mereka barulah Anda mulai menambahkan fitur ke produk Anda untuk mengkonsumsinya. Ini dapat membuat pengembangan lebih lancar (meskipun secara keseluruhan berpotensi lebih lambat, Anda akan cenderung mendapatkan kualitas yang lebih baik dan dapat dipahami)

Sunting: OK Saya melihat masalah Anda. Anda menganggap API sebagai pustaka jarak jauh. Ini bukan. Anggap layanan lebih sebagai layanan penyediaan data. Anda memanggil layanan untuk mendapatkan data dan kemudian melakukan operasi pada data itu secara lokal. Untuk menentukan apakah pengguna masuk, Anda akan memanggil " GetUser" dan kemudian melihat 'logged on'nilainya, misalnya. ( YMMV dengan contoh itu, tentu saja).

Contoh Anda untuk pembuatan pengguna massal hanya membuat alasan - tidak ada perbedaan di sini, apa pun yang Anda bisa lakukan dalam sistem monolitik masih dapat dilakukan dalam arsitektur layanan (misalnya Anda akan melewati array pengguna untuk membuat massal, atau satu untuk membuat. Anda masih dapat melakukan hal yang persis sama dengan layanan).

MVC sudah berdasarkan konsep layanan terisolasi, hanya kerangka kerja MVC yang mengikatnya menjadi satu proyek. Itu tidak berarti Anda kehilangan apa pun kecuali pembantu yang dibundel kerangka kerja Anda. Gunakan kerangka kerja yang berbeda dan Anda harus menggunakan pembantu yang berbeda. Atau, dalam hal ini, gulir sendiri (atau tambahkan langsung menggunakan perpustakaan).

Debugging juga mudah - Anda dapat menguji API secara menyeluruh sehingga Anda tidak perlu melakukan debug ke dalamnya (dan Anda dapat men-debug dari ujung ke ujung, Visual Studio dapat melampirkan ke beberapa proses secara bersamaan).

Hal-hal seperti kerja ekstra yang menerapkan keamanan adalah hal yang baik. Saat ini, jika Anda menggabungkan semua kode ke situs web Anda, jika seorang hacker mendapatkan akses ke sana, mereka juga mendapatkan akses ke semuanya, termasuk DB. Jika Anda membaginya menjadi API, peretas dapat melakukan sangat sedikit dengan kode Anda kecuali mereka juga meretas lapisan API juga - yang akan sangat sulit bagi mereka (pernah bertanya-tanya bagaimana penyerang mendapatkan daftar besar semua pengguna situs web atau rincian cc? Itu karena mereka meretas OS atau server web dan memiliki koneksi langsung ke DB di mana mereka dapat menjalankan " select * from users" dengan mudah).

Saya akan mengatakan bahwa saya telah melihat banyak situs web (dan aplikasi client-server) ditulis seperti ini. Ketika saya bekerja di industri jasa keuangan, tidak seorang pun akan pernah menulis situs web all-in-one, sebagian karena terlalu banyak risiko keamanan, dan sebagian karena banyak pengembangan GUI yang cantik dibandingkan pemrosesan data back-end yang stabil (yaitu warisan) sistem. Sangat mudah untuk mengekspos sistem DP sebagai situs web yang menggunakan arsitektur gaya layanan.

Sunting ke-2: Beberapa tautan pada subjek (untuk OP):

Perhatikan bahwa ketika membicarakan hal ini dalam konteks situs web, server web harus dianggap sebagai lapisan presentasi, karena itu adalah klien yang memanggil tingkatan lain, dan juga karena itu membangun tampilan UI yang dikirim ke browser untuk dirender. Ini adalah subjek besar, dan ada banyak cara untuk mendesain aplikasi Anda - data-sentris atau domain-sentris (saya biasanya menganggap domain sentris sebagai 'lebih murni', tapi YMMV ), tetapi semuanya bermuara pada menempelkan tingkat logika di antara klien Anda dan DB Anda. Ini sedikit seperti MVC jika Anda menganggap tengah, API, tier setara dengan Model Anda, hanya modelnya bukan pembungkus sederhana untuk DB, itu lebih kaya dan dapat melakukan lebih banyak lagi (mis. Data agregat dari 2 sumber data, posting -process data agar sesuai dengan API, cache data, dll.):

• Arsitektur multitier
• Membangun Aplikasi N-Tier di .NET
• Tutorial Youtube - lihat juga tautan terkait, termasuk yang akan diimplementasikan di C #
• Kursus pelatihan Pluralsight (percobaan gratis atau berbayar)

Anda tidak dapat menghindari membangun API . Bahkan jika Anda membangun "hanya sebuah Situs Web", masih harus mendapatkan datanya dari backend Anda. Namun Anda memutuskan untuk melakukan ini, itu adalah API de facto Anda .

Mengetahui hal ini, pertanyaan sebenarnya bukanlah apakah membangun API, tetapi bagaimana membangunnya . Anda dapat melakukannya dengan cepat sebagai hal yang bersifat sementara ( ad hoc) dan memang, banyak situs web yang dibuat dengan cara ini - atau Anda dapat mendesainnya dengan hati-hati agar dapat digunakan dalam konteks lain. Masukkan ke dalam konteks ini, menjadi sangat jelas bahwa kolega Anda benar: Anda harus melakukan API terlebih dahulu, dan kemudian membangun situs Anda di atasnya.

Namun demikian, ini membawa beberapa kekhawatiran, seperti yang Anda tunjukkan. Untuk mengatasinya:

Terlalu abstrak untuk menjalankan backend Anda dari API. Anda mencoba membuatnya terlalu fleksibel yang akan membuatnya berantakan.

Itu tergantung bagaimana Anda melakukannya. Seperti yang ditunjukkan George Pólya dalam teksnya yang sangat bagus How to Solve It , seringkali "masalah yang lebih umum mungkin lebih mudah untuk dipecahkan". Ini disebut Penemu Paradox . Dalam hal pemrograman, sering bekerja dengan cara memisahkan kekhawatiran: backend Anda tidak lagi harus peduli dengan format data yang dimasukkan dan dikeluarkan, sehingga kode dapat jauh lebih sederhana. Pengurai dan penyaji data Anda tidak lagi harus khawatir dengan apa yang terjadi pada data yang mereka buat, sehingga mereka juga bisa lebih sederhana. Semuanya bekerja dengan memecah kode menjadi potongan yang lebih mudah dikelola.

Semua hal yang dibangun dalam MVC tampaknya tidak berguna, seperti peran dan otentikasi. Misalnya, atribut [Keamanan] dan keamanan; Anda harus menggulung sendiri.

Saya mengakui bahwa saya merasa sangat sulit untuk bersimpati dengan orang-orang yang menolak untuk mempelajari alat mereka. Hanya karena Anda tidak mengerti penggunaannya tidak berarti bahwa mereka tidak berguna, dan itu tentu saja tidak berarti Anda harus menggulung sendiri . Justru sebaliknya; Anda tidak harus menggulung alat Anda sendiri sampai Anda memahami alternatifnya, sehingga Anda dapat memastikan untuk mengatasi masalah yang sama yang mereka lakukan (bahkan jika hanya dengan cara Anda sendiri).

Pertimbangkan Linus Torvalds , yang paling terkenal menulis Linux , tetapi yang juga menulis git : sekarang salah satu sistem kontrol versi paling populer di dunia. Salah satu faktor pendorong dalam desainnya adalah penentangan mendalam terhadap Subversion ( VCS lain yang sangat populer , dan bisa dibilang yang paling populer pada saat git ditulis); dia memutuskan untuk mengambil segala sesuatu yang dapat dilakukan Subversion, dan sejauh apa pun itu mungkin, menyelesaikan masalah-masalah itu secara berbeda. Untuk melakukan ini, ia harus menjadi ahli tentang Subversion dengan caranya sendiri , tepatnya sehingga ia dapat memahami domain masalah yang sama dan mengambil pendekatan yang berbeda.

Atau, dalam proses mempelajari alat Anda, Anda mungkin mendapati diri Anda menemukan bahwa itu berguna apa adanya, dan tidak perlu diganti.

Semua panggilan API Anda akan memerlukan informasi keamanan terlampir, dan Anda harus mengembangkan sistem token dan yang lainnya.

Iya. Beginilah seharusnya.

Anda harus menulis panggilan API lengkap untuk setiap fungsi yang akan dilakukan program Anda. Hampir setiap metode yang ingin Anda implementasikan harus dijalankan dari API. Dapatkan / Perbarui / Hapus untuk setiap pengguna, plus varian untuk setiap operasi lainnya, misalnya perbarui nama pengguna, tambahkan pengguna ke grup, dll. Dll. Dan masing-masing akan menjadi panggilan API yang berbeda.

Belum tentu. Di sinilah arsitektur seperti REST ikut bermain. Anda mengidentifikasi sumber daya yang digunakan aplikasi Anda, dan operasi yang masuk akal untuk diterapkan pada sumber daya itu, dan kemudian Anda menerapkannya tanpa terlalu mengkhawatirkan yang lain .

Anda kehilangan semua jenis alat seperti antarmuka dan kelas abstrak ketika datang ke API. Hal-hal seperti WCF memiliki dukungan yang sangat lemah untuk antarmuka.

Sebaliknya, antarmuka menjadi jauh lebih penting ketika Anda menggunakan API, tidak kurang . Mereka muncul dalam representasi yang Anda berikan. Sebagian besar orang saat ini menentukan format berbasis JSON untuk ini, tetapi Anda dapat menggunakan format apa pun yang Anda inginkan, selama Anda menentukannya dengan baik. Anda membuat output panggilan Anda ke format ini di backend, dan menguraikannya menjadi apa pun yang Anda inginkan (kemungkinan jenis objek yang sama) di frontend. Biaya overhead kecil, dan keuntungan dalam fleksibilitas sangat besar.

Anda memiliki metode yang menciptakan pengguna, atau melakukan beberapa tugas. Jika Anda ingin membuat 50 pengguna, Anda bisa menyebutnya 50 kali. Ketika Anda memutuskan untuk melakukan metode ini sebagai API, server web Anda dapat menamainya dengan pipa bernama dan tidak ada masalah - klien desktop Anda juga dapat melakukannya, tetapi tiba-tiba kreasi pengguna massal Anda akan melibatkan pemalu API melalui Internet 50 kali yang tidak bagus Jadi Anda harus membuat metode massal, tetapi sebenarnya Anda hanya membuatnya untuk klien desktop. Dengan cara ini, Anda pada akhirnya harus a) memodifikasi API Anda berdasarkan apa yang diintegrasikan dengannya, dan Anda tidak bisa langsung berintegrasi dengannya, b) melakukan lebih banyak pekerjaan untuk membuat fungsi tambahan.

Membuat versi massal dari metode yang ada bukanlah sesuatu yang saya sebut "lebih banyak pekerjaan". Jika Anda tidak khawatir tentang hal-hal seperti atomicity, metode massal dapat berakhir menjadi tidak lebih dari tampilan yang sangat tipis untuk aslinya.

YAGNI . Kecuali jika Anda secara khusus berencana untuk menulis dua aplikasi yang berfungsi identik, satu web dan satu aplikasi Windows misalnya, itu adalah sejumlah besar pekerjaan pengembangan tambahan.

Tidak, YANI (Anda Sudah Membutuhkannya). Saya menguraikan itu seperti di atas. Satu-satunya pertanyaan adalah berapa banyak pekerjaan desain untuk dimasukkan ke dalamnya.

Debugging jauh lebih sulit ketika Anda tidak dapat melangkah dari ujung ke ujung.

Mengapa Anda tidak bisa melangkah dari ujung ke ujung?

Tapi yang lebih penting, bisa memeriksa data bolak-balik dalam format yang mudah dikenali yang memotong semua tampilan layar sebenarnya cenderung membuat proses debug lebih mudah , bukan lebih sulit.

Banyak operasi independen yang akan membutuhkan banyak bolak-balik, misalnya beberapa kode mungkin mendapatkan pengguna saat ini, periksa pengguna di peran administrator, dapatkan perusahaan milik pengguna, dapatkan daftar anggota lain, kirim semua anggota email. Itu akan membutuhkan banyak panggilan API, atau menulis metode khusus tugas khusus yang Anda inginkan, di mana satu-satunya manfaat metode dipesan lebih dahulu adalah kecepatan, tetapi downside akan menjadi tidak fleksibel.

REST memecahkan ini dengan bekerja pada objek lengkap ( sumber daya , untuk menggunakan istilah teori REST), daripada sifat individu objek . Untuk memperbarui nama pengguna, Anda DAPATKAN objek pengguna, ubah namanya, dan PUT pengguna kembali. Anda mungkin membuat perubahan lain pada saat yang sama saat Anda mengubah nama pengguna juga. Masalah yang lebih umum menjadi lebih mudah untuk dipecahkan, karena Anda dapat menghilangkan semua panggilan individu untuk memperbarui properti individu dari suatu objek: Anda hanya memuat dan menyimpannya.

Dalam beberapa hal, ini tidak seperti arsitektur RISC di sisi perangkat keras. Salah satu perbedaan utama antara RISC dan CISC (pendahulunya) adalah bahwa arsitektur CISC cenderung mencakup banyak instruksi yang beroperasi langsung pada memori, sedangkan arsitektur RISC cenderung beroperasi sebagian besar dalam register: dalam arsitektur RISC murni, satu-satunya operasi pada memori adalah LOAD (salin sesuatu dari memori ke register) dan STORE (ambil nilai dari register dan masukkan ke dalam memori).

Anda akan berpikir bahwa ini berarti mengambil lebih banyak perjalanan dari register ke memori, yang akan memperlambat mesin. Namun dalam praktiknya, yang terjadi adalah sebaliknya: prosesor (klien) bekerja lebih banyak di antara perjalanan ke memori (server) , dan dari sinilah percepatan berasal.

Singkat cerita: kolega Anda benar. Ini cara untuk pergi. Sebagai gantinya untuk sedikit pekerjaan di muka, itu akan secara dramatis menyederhanakan kode untuk Situs Web Anda dan memungkinkan integrasi yang lebih baik dengan Situs dan aplikasi lain. Itu adalah harga yang pantas dibayar.

Bacaan lebih lanjut:

1. REST API Design - Pemodelan Sumber Daya

Saya tahu layanan mikro adalah hal yang sangat disukai saat ini, tetapi mereka tidak selalu sepadan. Ya, kode yang digabungkan secara longgar adalah tujuannya. Tapi itu tidak harus mengorbankan siklus pengembangan yang lebih menyakitkan.

Jalan tengah yang baik adalah membuat proyek data terpisah dalam solusi Anda. Proyek data akan menjadi perpustakaan kelas .NET. Proyek ASP.NET MVC Anda kemudian akan menambahkan referensi ke pustaka data, dan semua model akan ditarik dari proyek data. Kemudian ketika saatnya tiba untuk membuat aplikasi desktop atau seluler, Anda bisa merujuk kode yang sama. Jadi itu mungkin bukan API resmi, tetapi akan berfungsi sebagai satu. Jika Anda ingin membuatnya dapat diakses sebagai API, Anda bisa membuat proyek web sederhana yang bertindak sebagai pembungkus pada proyek data.

Microsoft telah mempromosikan konsep ini, yang mereka sebut Perpustakaan Kelas Portabel .

Tidak seharusnya tidak . Jika Anda tidak memiliki rencana segera untuk membuat antarmuka alternatif (seperti aplikasi seluler atau desktop atau aplikasi web terpisah) yang mengakses backend yang sama, maka Anda tidak boleh memperkenalkan lapisan layanan web. YAGNI .

Kopling longgar selalu diinginkan (bersama dengan kohesi tinggi), tetapi itu adalah prinsip desain dan tidak berarti Anda harus memisahkan objek secara fisik pada server yang berbeda! Dan API layanan yang dirancang dengan buruk dapat membuat kopling ketat melintasi batas server, jadi memiliki API tidak menjamin kopling longgar.

Jika kebutuhan akan API layanan harus muncul di masa mendatang, Anda selalu dapat memperkenalkannya pada saat itu. Selama Anda menyimpan kode Anda dengan baik (akses data dan logika bisnis dipisahkan dengan rapi dari logika UI), tidak akan lebih sulit untuk memperkenalkannya lebih lambat daripada sekarang. Dan desain yang dihasilkan akan jauh lebih baik ketika dirancang untuk memenuhi persyaratan aktual.

Catatan Saya mengasumsikan pertanyaannya adalah apakah Anda harus membuat API layanan web atau tidak. Pertanyaannya hanya mengatakan API, tetapi API juga bisa berarti antarmuka perpustakaan, dan tentu saja setiap lapisan akan memiliki API menurut definisi. Intinya adalah bahwa logika bisnis dan lapisan akses data Anda harus dipisahkan dengan rapi dari logika UI di tingkat desain, tetapi Anda tidak boleh memperkenalkan lapisan layanan web jika Anda tidak membutuhkannya.

Perusahaan saya memiliki satu aplikasi yang dibangun seperti ini. Awalnya kami ditugaskan untuk membangun back end dengan API untuk front end yang dibuat pengembang lain. Ketika pengembang lain tidak dapat mengembangkan ujung depan itu, kami ditugaskan untuk membangun ujung depan juga. Meskipun pasti ada manfaat dari pendekatan ini, ada kerugian besar: biaya. Membangun awal akan secara signifikan lebih mahal, dan pemeliharaan yang sedang berlangsung akan lebih mahal, karena lebih banyak kode untuk mempertahankan dan memiliki dua sistem terpisah juga digunakan. Karena biaya tambahan, ini harus selalu menjadi keputusan bisnis, bukan diambil atas kemauan oleh pengembang.

Untuk menghitungnya, saya akan memperkirakan proyek yang saya sebutkan di atas biaya 20% lebih karena pendekatan ini. Anda tidak menggambarkan jenis proyek yang sedang Anda kerjakan pada perusahaan tempat Anda bekerja, tetapi jika Anda baru mulai membangun produk mereka, biaya tambahan itu bisa menjadi perbedaan antara pengiriman beberapa fitur tambahan yang membuat produk Anda sebuah kesuksesan.

Alasan lain untuk tidak, setidaknya tidak secara universal, adalah bahwa jika atau ketika Anda memutuskan untuk membuat antarmuka kedua, jarang ada pemetaan fungsi satu-ke-satu. Jika Anda membuat aplikasi seluler, misalnya, mereka cenderung memiliki lebih sedikit fitur. Ini berarti beberapa metode API Anda tidak akan pernah digunakan kembali. Karenanya, kompromi dengan kolega Anda mungkin untuk memutuskan di antara Anda panggilan yang paling penting / kritis dan menambahkannya ke API, dan menggunakan metode yang lebih tradisional untuk yang lainnya.

Hal lain yang perlu dipertimbangkan adalah bahwa kolega Anda mengatakan Anda tidak akan dapat menggunakan kembali kode yang ada, yang tidak benar jika Anda memiliki beberapa pemisahan logika bisnis Anda. Anda hanya perlu membuat pembungkus layanan web tipis di sekitar API internal Anda, yang bukan tugas besar. Akan naif untuk berpikir Anda bisa menggunakan kembali lapisan layanan web untuk ujung depan yang lain tanpa perubahan sama sekali.

Itu tergantung pada jenis aplikasi dan jenis pasar Anda.

Ada trade-off dan manfaat untuk pergi dengan cara ini. Ini bukan jawaban yang jelas bahwa satu cara lebih baik daripada yang lain.

Saya akan berbicara dari pengalaman pribadi. Saya adalah orang yang memutuskan untuk mengambil basis kode yang saya kerjakan dalam arah ini kembali pada tahun 2007. basis kode itu ada di urutan jutaan baris kode sekarang, setengah dari yang merupakan kode server tersembunyi di balik sejumlah besar layanan web API, setengah lainnya adalah armada klien, desktop asli, desktop web, mobile, integrasi back-end, dll ... Keputusan ini bukan tanpa kerugian, tetapi dengan 20/20 belakang saya bisa mengatakan saya akan melakukannya lagi . Biarkan saya menunjukkan beberapa trade-off yang terlibat.

Manfaat

• Fleksibilitas. Baik itu permintaan untuk membangun aplikasi seluler untuk menambah pengalaman desktop, atau permintaan untuk berintegrasi dengan SAP, semuanya menjadi lebih mudah ketika Anda sudah memiliki API untuk dihubungi. Ketika Anda mendapatkan cukup dari permintaan ini, Anda akan berkembang secara organik menuju API, dan satu-satunya pertanyaan adalah apakah itu memiliki layanan web standar di depannya, atau apakah itu adalah API internal di mana layanan web dibuat khusus.

• Skalabilitas (dari tim). Dalam kasus kami, kami memiliki banyak grup pengembang yang berbeda yang membangun di atas API ini. Kami bahkan telah mendedikasikan tim API, yang berbicara dengan berbagai kelompok, merangkum kebutuhan, dan membuat API semua tujuan. Sudah sampai pada titik di mana kita bahkan tidak diberitahu lagi bahwa orang-orang membangun hal-hal di atas API, dan tidak semua orang yang melakukan itu bekerja untuk perusahaan kita.

• Keamanan. Memiliki pembagian yang jelas antara bagian basis kode Anda yang tidak aman dan aman sangat membantu dalam mempertimbangkan keamanan. Mengacaukan UI dan kode back-end bersama-sama cenderung membingungkan.

Pertukaran

• Fleksibilitas. Anda harus melakukan pekerjaan untuk "benar" membangun sesuatu ke dalam API. Tidak mungkin menjalankan kueri DB dengan cepat dari dalam kode UI untuk menyelesaikan masalah tertentu. Juga, API yang sebenarnya dapat digunakan kembali harus memperhitungkan begitu banyak kasus penggunaan sehingga solusi cepat biasanya merupakan solusi yang salah. API menjadi kurang fleksibel untuk berevolusi, terutama karena sudah ada banyak kode klien di luar sana (kami beralih ke API versi karena alasan itu).

• Kecepatan pengembangan awal. Lebih lambat mengembangkan API-pertama, tanpa sedikit pun keraguan. Anda hanya memenangkannya kembali ketika Anda memiliki cukup banyak klien yang dibangun di atas API. Tetapi kemudian Anda menemukan bahwa Anda membutuhkan 3 implementasi klien yang berbeda sebelum API Anda berkembang menjadi cukup umum. Kami menemukan bahwa sebagian besar desain API awal kami salah dan harus sangat merevisi pedoman kami tentang cara membangun layanan web.

ikan haring merah

Anda menyebutkan banyak dari ini. Mereka sebenarnya tidak penting dalam praktik.

• Abstraksi. API Anda menjadi cukup abstrak untuk mencakup semua kasus penggunaan yang perlu dilayani oleh produk Anda, dan tidak lebih dari itu. Bahkan tanpa layanan web Anda akan memiliki API internal yang melakukan ini, atau memiliki banyak kode duplikat. Saya lebih suka abstraksi daripada duplikasi.

• Meninggalkan tumpukan MVC sisi server. Saat ini hampir setiap sistem akan membutuhkan aplikasi seluler untuk sementara waktu Ketika Anda kemudian membangun layanan web untuk memenuhi aplikasi seluler itu, Anda harus mencari tahu bagaimana melakukan otentikasi dan otorisasi dalam konteks API. Ini sebenarnya kurang bekerja ketika Anda hanya memiliki satu cara untuk melakukan itu, cara Anda melakukannya di layanan web Anda.

• Operasi massal. Biasanya dipecahkan dengan membuat API massal yang meluncurkan pekerjaan back-end dan mengembalikan id pekerjaan untuk pencarian status. Bukan masalah besar.

• Debugging. Saya menemukan bahwa secara keseluruhan menjadi sedikit lebih mudah untuk memecahkan masalah sistem. Anda masih dapat menetapkan breakpoints dalam kode front-end dan back-end, jadi dalam praktiknya tidak begitu sulit untuk dilewati, dan Anda mendapatkan kemampuan untuk membuat tes api otomatis dan untuk memasukkan api untuk memantau sistem produksi.

• Banyak operasi independen. Itu masalah bagaimana Anda merancang sesuatu. Jika Anda bersikeras memiliki API CRUD murni, maka ya, Anda akan menderita masalah ini. Tetapi memiliki beberapa API CQRS untuk ditambah yang biasanya merupakan ide yang baik, dan jika Anda telah memastikan bahwa Anda memiliki API internal yang layanannya merupakan ujung depan, maka Anda dapat dengan mudah menggunakan kembali API internal itu untuk membangun layanan bagi mereka yang spesifik skenario.

Singkatnya

Dalam sistem yang digunakan dalam konteks yang cukup berbeda, API secara alami akan berkembang karena merupakan cara termudah untuk memenuhi semua kebutuhan. Tapi pasti ada kasus YAGNI yang terjadi. Ada kompromi dan itu tidak masuk akal sampai masuk akal. Poin kuncinya adalah untuk tidak dogmatis dan tetap berpikiran terbuka terhadap berbagai pendekatan dalam arsitektur untuk memenuhi kebutuhan produk yang berkembang.

Apa yang dijelaskan oleh kolega Anda adalah arsitektur berorientasi layanan. Ini bisa menjadi cara yang sangat scalable, dapat diuji dan cara yang waras untuk kode, tetapi itu benar-benar tergantung pada apa yang Anda buat.

Ada beberapa manfaat signifikan untuk SOA, yang akan saya coba sebutkan:

Skalabilitas

Karena ujung belakang Anda dipisahkan, ujung depan Anda menjadi serangkaian template, bahkan flatfiles. Flatfiles sangat cepat dan murah untuk dilayani dari CDN apa pun. Mereka dapat diperkecil dan dikompilasi ke dalam HTML statis, kemudian diisi dengan data klien.

API Anda harus tetap konsisten, tetapi dapat ditukar dengan teknologi yang lebih cepat tanpa memecahkan tumpukan Anda jika Anda melebihi teknologi yang ada. Anda bisa membuat ulang di Go misalnya. Anda dapat membangunnya kembali sedikit demi sedikit dan menyebar beban ke seluruh server. Selama antarmuka tetap sama, teknologi diabstraksikan.

Testabilitas

MVC biasanya dimulai dengan bersih, tetapi dalam praktiknya pengendali jarang tetap fokus pada satu sumber daya. Semakin banyak hal yang dilakukan oleh metode pengontrol Anda, semakin tidak teruji.

API menghindari masalah ini. Setiap panggilan API menarik sumber daya dan menyajikannya. Bersih dan dapat diuji.

Dijamin pemisahan keprihatinan

Ujung depan dan ujung belakang Anda sepenuhnya cerai. Anda dapat memberikan ujung depan kepada pengembang atau desainer lain. Ini MVC dibawa ke tingkat lain. Saya yakin Anda tidak ingin menyerah pada MVC. SOA adalah MVC tetapi lebih-lebih.

Kerugian

Tentu saja ada beberapa kerugian. Monolith sering kali lebih cepat digunakan. Mungkin sudah terbiasa dengan Anda. Ini mungkin lebih pas di tumpukan Anda. Alat Anda dapat dioptimalkan untuk pembuatan monolit.

Tidak satu pun dari ini adalah alasan yang sangat bagus menurut saya, dan Anda mungkin ingin mempertimbangkan memperlengkapi kembali jika mereka berlaku untuk Anda.

Ada banyak jawaban bagus di sini jadi saya hanya akan menambahkan pengalaman implementasi saya.

Ini cara saya melakukan hal-hal:

• Buat Layer Akses Database yang menangani semua / hanya interaksi DB (biasanya SQL manual digunakan untuk kecepatan dan kontrol, tanpa ORM) . Sisipkan, Perbarui, Hapus, Pilih ...
• Buat sebuah interface(virtual class ) yang mengekspos / menegakkan fungsi API yang saya butuhkan. Mereka akan, ketika diimplementasikan, menggunakan fungsi DBAL yang sangat terspesialisasi untuk mencapai hasil. Ini juga membantu saya untuk menegakkan API di tingkat kompiler jadi saya memastikan implementasi Server + API memiliki semua fungsi bawaan.
• Buat Lapisan Kedua yang mengimplementasikan antarmuka (ini adalah API yang sebenarnya) dan memberlakukan pembatasan keamanan. Anda juga berinteraksi dengan API eksternal di sini.
• Situs web akan menggunakan Lapisan Kedua secara langsung (untuk kinerja) tanpa melalui API yang dapat diakses dari jarak jauh (seperti SOAP, JSON) .
• Server mandiri dibuat dengan mengimplementasikan antarmuka dan mengekspos Lapisan Kedua sebagai API yang dapat diakses dari jarak jauh ke klien desktop / seluler eksternal (akses non-situs web) . Semua yang dilakukannya adalah mendekode permintaan dan menyandikan respons dan mengelola / memutuskan klien. Ini juga mendukung kemampuan pushback untuk memberi tahu secara massal klien tentang peristiwa yang dihasilkan oleh rekan lain yang terhubung (fungsionalitas yang biasanya tidak diperlukan situs web) .

Jadi, secara teknis, API adalah Lapisan Kedua. Anda menggunakannya secara langsung dengan situs web dan mengeksposnya ke klien jarak jauh melalui server. Kode digunakan kembali dan tidak pernah ada bagian kode yang dapat digunakan kembali. (hidup dan mati dengan aturan ini dan semuanya luar biasa) Membantu dengan pemeliharaan, pengujian ... semuanya.

Anda tidak pernah menghubungkan situs web ke desktop / server API seluler (kecuali situs Anda AJAX dan berjalan di JSON) . Tetapi jika situs membuat konten dinamis di markup, melalui API perantara akan menembak kinerja Anda. Situs web harus cepat! Akses klien jarak jauh bisa sedikit lebih lambat.

PS : Ya, perawatannya sedikit lebih rumit karena lebih banyak roda bekerja bersama tetapi lebih mudah dalam jangka panjang. Jadi, jika proyek Anda dimaksudkan untuk hidup sementara dan sedikit rumit, selalu miliki API. Ini juga jauh lebih mudah untuk menguji setiap lapisan sendiri.

Titik pertengkaran bukanlah jika Anda harus menggunakan API, tetapi apa sebenarnya "API" itu. Satu-satunya alternatif untuk menggunakan API yang dirancang adalah dengan menggunakan API yang merupakan kekacauan kode acak. Anda menulis bahwa API membuat hal-hal "terlalu fleksibel" yang pada gilirannya membuat hal-hal tidak terkelola. Ini menunjukkan kesalahpahaman yang lengkap dan menyeluruh tentang apa itu API. Jika kesalahpahaman itu tidak dibagi antara Anda dan rekan kerja Anda, maka Anda membuang banyak waktu dengan berdebat tentang hal-hal yang sama sekali berbeda.

Dengan tidak menggunakan API yang terdefinisi dengan baik, Anda dapat melakukan apa pun yang Anda inginkan. Menurut definisi, ini adalah opsi yang paling fleksibel. Juga, menurut definisi "melakukan apa pun yang Anda inginkan" masih merupakan API. Satu- satunya tugas API adalah menghapus fleksibilitas. Dengan menghapus fleksibilitas, API yang baik mendorong pengguna untuk melakukan hal serupa dengan cara yang serupa.

Tentu saja API yang buruk dapat memberikan fleksibilitas yang terlalu banyak atau terlalu sedikit, atau bahkan keduanya sekaligus. API yang dirancang sangat buruk dapat membunuh proyek lebih cepat daripada pendekatan "apa pun". Namun, praktik terbaik hanya untuk memiliki programmer yang kompeten yang mengembangkan dan mengembangkan API bersama aplikasi Anda.

Contoh

• Banyak operasi independen yang akan membutuhkan banyak bolak-balik, misalnya beberapa kode mungkin mendapatkan pengguna saat ini, periksa pengguna di peran administrator, dapatkan perusahaan milik pengguna, dapatkan daftar anggota lain, kirim mereka semua email. Itu akan membutuhkan banyak panggilan API, atau menulis metode khusus tugas khusus yang Anda inginkan, di mana satu-satunya manfaat metode dipesan lebih dahulu adalah kecepatan, tetapi downside akan menjadi tidak fleksibel.

Jumlah panggilan API yang diperlukan pada API yang layak mungkin 1. Ya, tidak fleksibel, tetapi mengapa Anda ingin fleksibel?

Dia mengatakan bahwa kode kita terlalu erat. Misalnya, jika kami menginginkan aplikasi desktop juga, kami tidak akan dapat menggunakan kode yang ada.

Baiklah, kan? Jika tidak, maka itu pernyataan yang sangat tidak relevan.

Saya katakan, jika Anda akan membangun aplikasi baru pada tahun 2015, maka serius melihat ke sesuatu dengan antarmuka pengguna yang melibatkan API dan bukan server yang dihasilkan halaman HTML. Ada biaya yang jelas tetapi juga manfaat yang jelas.

Tetapi jika Anda memiliki situs yang sudah ada tanpa rencana konkret untuk memiliki beberapa antarmuka yang berbeda (sejauh yang saya tahu), maka komentarnya tidak relevan.

Versi Singkat: Pengontrol Anda secara efektif API apa pun yang terjadi; meskipun ASP.NET mungkin mengaburkan itu.

Versi yang lebih panjang:

Pikirkan tentang Aplikasi Web MVC dasar yang menyediakan informasi tentang bir dan secara opsional menjualnya kepada Anda. Seperti apa rute itu?

/sign_in
/sign_out
/beer
/beer/{beer_name}
/order
/order/{order_number}

Dalam aplikasi web normal, ada kemungkinan beberapa rute tambahan seperti:

/beer/new
/beer/{beer_name}/edit
/beer/{beer_name}/delete
/order/new
/order/{order_number}/edit
/order/{order_number}/delete

Di API Web, itu tidak diperlukan, karena disimpulkan dari metode HTTP.

Mengingat simetri di atas, saya pikir ini membuat kasus yang cukup menarik bahwa API dan Pengendali Anda sangat dekat sehingga mereka mungkin juga menjadi hal yang sama.

Setelah melakukan penggalian, saya telah menentukan bahwa ini mungkin keadaan untuk Anda tergantung pada versi ASP.NET yang Anda gunakan. MVC 5 yang lebih lama dan sebelumnya tidak memiliki konvensi dan antarmuka untuk menyatukan kedua implementasi dengan baik. Dalam versi lama, pengembalian Web App mengisi Tampilan sedangkan API memberikan HttpResponse. Namun dalam kedua kasus, mereka menghasilkan respons yang persis sama secara semantik.

Jika Anda menggunakan MVC 6, Anda mendapatkan keduanya di kelas pengontrol terpadu yang bisa pintar tentang apa yang dikembalikan. Saya belum menemukan kode contoh ASP yang bagus untuk model ini, tetapi saya telah menemukan beberapa kode Rails dengan pola yang sama. Pertimbangkan pengontrol ini untuk "suka" dari proyek Diaspora . Setiap metode pengontrol memiliki rute yang ditentukan oleh "konvensi akal" di sini yang berjumlah LCRUD dalam API.

Jika Anda membaca implementasinya, masing-masing dapat merespons HTML, HTML Mobile, atau JSON. Ini, dikombinasikan dengan konvensi untuk menemukan tampilan, sepenuhnya menyatukan Aplikasi Web dan API Web. Anda juga akan mencatat bahwa tidak semua metode benar-benar memberikan setiap respons (yang masuk akal, karena UI mungkin memerlukan metode yang tidak akan dilakukan API, dan sebaliknya).

Ini adalah ketidakcocokan impedansi karena jenis ASP.NET menemukan semua ini terlambat sedangkan Rails telah memeluk simetri untuk beberapa waktu dan membuatnya sangat jelas.

Spekulasi:

Rekan kerja Anda mungkin benar dan salah, tergantung pada versi ASP yang Anda gunakan. Di bawah versi MVC lama, perbedaan antara API dan App mungkin memang membuatnya menjadi "praktik terbaik" untuk membangun API di muka karena model ASP.NET tidak benar-benar memungkinkan untuk menggunakan kembali kode yang baik di sana.

Dengan yang lebih baru, lebih masuk akal untuk menggunakan kode terpadu karena lebih mudah untuk menggunakan kembali kode dengan kelas dasar kontroler terpadu.

Namun dalam kedua kasus tersebut, Pengontrol secara efektif adalah API.

Ketika saya memulai karir saya pada tahun 2006, jenis arsitektur ini adalah yang paling populer di dunia .NET. Saya bekerja di 3 proyek terpisah dikandung pada pertengahan 2000-an dengan layanan web antara lapisan logika bisnis dan antarmuka web. Tentu saja hari ini layanan web SOAP tetapi arsitekturnya masih sama. Manfaat yang seharusnya adalah kemampuan untuk beralih baik depan atau belakang dan bahkan mengembangkan program desktop. Akhirnya YAGNI terbukti benar. Saya tidak pernah melihat ini terjadi. Selama ini saya hanya melihat biaya pemisahan proyek dengan cara ini. Saya bahkan akhirnya merobek layanan web dari salah satu proyek (butuh setengah tahun untuk menghapusnya langkah demi langkah sambil melakukan hal-hal lain) dan seluruh tim senang. Saya tidak pernah mencoba pendekatan itu sejak itu dan saya tidak akan kecuali diberikan alasan yang sangat spesifik. 5 tahun pengalaman mencoba arsitektur ini mengajarkan saya bahwa saya tidak akan membutuhkannya dan tidak ada ahli yang mengatakan yang sebaliknya yang akan meyakinkan saya bahwa saya akan melakukannya. Hanya proyek di mana saya membutuhkannya yang dapat melakukannya.

Sekarang sedang dikatakan saya berusaha keras untuk mengembangkan lapisan antara logika bisnis dan pengontrol / presenter. Sebagai contoh saya memiliki lapisan layanan, saya tidak pernah mengekspos queriables, menggunakan antarmuka untuk semua layanan saya dan menyuntikkan mereka di controller dengan IoC. Jika saya membutuhkan layanan web dalam arsitektur saya, saya akan dapat memperkenalkannya dengan biaya yang masuk akal. Saya hanya tidak ingin membayar biaya ini di muka.

Saya juga cukup menyukai ide microservices tetapi pemahaman saya adalah bahwa microservices berarti modul vertikal daripada lapisan horizontal. Misalnya jika Anda membangun facebook, fitur obrolan akan menjadi layanan terpisah yang digunakan secara terpisah di server sendiri, dll. Ini adalah jenis layanan independen yang saya dorong.

Pihak ketiga akan menggunakannya? Ya kamu harus .

Anda berencana untuk menggunakannya kembali dalam waktu yang tidak terlalu lama? Ya kamu harus.
Anda akan menjadi pihak ketiga Anda , memiliki API yang terdokumentasi - atau dapat didokumentasikan - atau dapat digunakan oleh pihak ketiga akan memberi Anda usabilitas dan modularitas yang solid.

Anda terburu-buru? Tidak, seharusnya tidak.
Refactoring sesudahnya lebih mudah dan lebih cepat daripada kebanyakan metodologi dan guru yang memprediksi dan memberi tahu. Lebih penting memiliki sesuatu yang berfungsi (bahkan dengan desain internal yang buruk, karena dapat dan akan di-refactored) daripada tidak memiliki apa-apa sama sekali. (tetapi dengan desain internal yang luar biasa , wohoo)

Front-end mungkin tidak pernah melihat cahaya hari ini karena alasan? Ya kamu harus .
Saya menambahkan alasan ini karena, yah, ini banyak terjadi pada saya.
Dan setidaknya saya pergi dengan komponen saya untuk menggunakan kembali dan mendistribusikan kembali dll.

Ada jawaban yang bagus di sini. Saya memposting ini sebagai jawaban parsial; mungkin akan lebih baik sebagai komentar. Namun menempel komentar yang sama pada banyak posting tidak baik.

Seseorang tidak dapat mengklaim YAGNI adalah alasan untuk tidak membuat API.

API adalah titik akhir pengujian alami dan logis. Jadi sejak hari 0, ada dua aplikasi yang menggunakan API: UI dan suite pengujian. Satu dimaksudkan untuk manusia, yang lain ditujukan untuk mesin. Mereka tentu berbeda. Menguji perilaku front-end adalah tugas yang jauh berbeda dari menguji perilaku back-end. Jadi tekniknya, dan mungkin alatnya, sangat berbeda. API memungkinkan alat terbaik untuk digunakan untuk pekerjaan itu. Selanjutnya, dengan pemisahan yang diberikan oleh API, penguji front-end tidak harus menguji fungsi back-end.

API juga membantu menjaga pembuat kode front-end dari keprihatinan pembuat kode back-end, dan sebaliknya. Ini adalah keterampilan yang sangat berbeda di perusahaan kami; API memungkinkan kita untuk fokus di tempat kita paling kuat.