REST dirancang untuk web, dan web dirancang untuk REST. Keduanya pas akan bersama-sama. Tesis 2.000 PhD Roy Fielding, Gaya Arsitektur dan Desain Arsitektur Perangkat Lunak Berbasis Jaringan mendefinisikan dan memperkenalkan istilah REST , dan terdapat interaksi yang signifikan antara web dan REST: Roy Fielding bekerja pada HTTP / 1.1, di mana ia adalah penulis utama, dan dia menggunakan apa yang dia pelajari di sana untuk menggambarkan REST dalam disertasinya.
Jadi, alasan sederhana mengapa web dan REST berjalan sangat baik bersama adalah bahwa definisi REST diambil dari bagaimana web bekerja, dan web adalah implementasi dari REST.
Itu sebabnya REST sangat cocok untuk layanan web dan aplikasi web: karena Anda hanya melakukan hal yang sama yang telah terbukti bekerja di web "manusia", dan menerapkannya ke web "mesin".
Masalah besar dengan RPC (tergantung pada implementasi yang tepat ) pada dasarnya terletak pada Fallacy of Distributed Computing , yang dijelaskan secara lebih rinci dalam whitepaper ini oleh Arnon Rotem-Gal-Oz :
- Jaringan ini dapat diandalkan
- Latensi adalah nol
- Bandwidth tidak terbatas
- Jaringan aman
- Topologi tidak berubah
- Ada satu administrator
- Biaya transportasi nol
- Jaringannya homogen
Ini semua adalah asumsi yang biasanya dibuat oleh pendatang baru ketika mereka mulai membuat sistem terdistribusi. Tentu saja, semua itu salah. Dan Anda perlu memperhitungkan semuanya saat membuat sistem terdistribusi.
Masalah dengan banyak implementasi RPC adalah mereka mencoba membuat panggilan jarak jauh terlihat seperti panggilan lokal. Tetapi mereka tidak sama:
- panggilan lokal tidak pernah gagal; yang subroutine yang Anda disebut mungkin gagal, tetapi panggilan itu sendiri tidak pernah melakukan - panggilan jarak jauh mungkin tersesat pada jaringan
- panggilan lokal bersifat instan; yang subroutine yang Anda disebut dapat menjalankan untuk waktu yang lama (atau bahkan selamanya jika mendapat terjebak dalam infinite loop), namun panggilan itu sendiri membutuhkan waktu sama sekali (baik, beberapa petunjuk CPU paling banyak, kurang jika panggilan tersebut sebaris, tetapi sangat cepat) - panggilan jarak jauh mungkin macet di jaringan untuk waktu yang lama
- jika subrutin kembali normal, hasilnya selalu kembali - dengan panggilan jarak jauh, hasilnya mungkin hilang di jaringan
- pengembalian bersifat instan - hasil jarak jauh dapat melakukan perjalanan di jaringan untuk waktu yang lama
- jika saya memanggil subrutin sekali, itu akan berjalan tepat sekali - panggilan jarak jauh mungkin hilang di jaringan, atau digandakan sehingga rutin jarak jauh dapat berjalan antara 0 dan berapa kali
- Saya mendapatkan kembali tepat satu hasil - hasil jarak jauh mungkin hilang atau terduplikasi, sehingga Anda bisa mendapatkan hasilnya 0 kali atau lebih
- jika saya memanggil subrutin dua kali, saya mendapatkan dua hasil dan saya mendapatkan hasil dari panggilan pertama sebelum hasil dari panggilan kedua - Anda mungkin dapat menebaknya sekarang: dengan RPC, Anda mungkin tidak mendapatkan kembali hasil, atau hanya yang pertama , atau hanya yang kedua, atau yang kedua sebelum yang pertama, atau yang pertama bisa hilang dan Anda mendapatkan yang kedua dua kali, atau sebaliknya, dan seterusnya ...
- jika saya menelepon
adan kemudian b, saya mendapatkan kembali hasil adan kemudian hasil b - ini hanya versi yang lebih umum dari poin sebelumnya, dengan RPC, Anda dapat memperoleh salah satu dari dua jawaban 0 kali atau lebih dalam urutan apa pun
Anda akan harus berurusan dengan semua di atas untuk panggilan jarak jauh. Tetapi jika kerangka kerja Anda membuat panggilan jarak jauh tidak dapat dibedakan dari panggilan lokal, maka Anda tidak bisa , karena Anda tidak tahu mana yang merupakan panggilan jarak jauh. Kerangka kerja mungkin mencoba dan menangani semua itu untuk Anda, tetapi masalahnya adalah: kerangka kerja tidak tahu sebanyak mungkin tentang sistem Anda. Tidak tahu apakah ada panggilan di mana sebenarnya tidak masalah jika seseorang tersesat sesekali. Jadi, kerangka kerjanya harus sangat defensif, dan itu mahal dalam hal latensi dan bandwidth.
Terutama karena kerangka itu sebenarnya tidak bisa melindungi Anda. The CAP Teorema mengatakan bahwa sebuah sistem terdistribusi tidak bisa Konsisten, Tersedia, dan Partisi-Toleransi pada saat yang sama; lebih tepatnya, dikatakan bahwa begitu Partisi terjadi, sistem tidak dapat terus menjadi Konsisten dan Tersedia, ia harus memilih satu (bertentangan dengan kepercayaan populer, teorema tidak mengatakan bahwa Anda tidak dapat memiliki ketiganya, ketika sistem sedang berjalan biasanya, Anda dapat memiliki ketiganya, tetapi begitu Anda memiliki Partisi, Anda harus memilih salah satu dari dua lainnya). The PACELC Teorema memperluas CAP Teorema dengan menunjukkan bahwa bahkan ketika sistem bekerja, Anda harus trade-off Latency vs Konsistensi.
Ini adalah kompromi penting yang tidak dapat dilindungi oleh kerangka kerja Anda, karena mereka spesifik domain dan penting bagi desain inti.
Kontras ini dengan pendekatan seperti Erlang, yang tidak bekerja: di Erlang, semua pesan mengirimkan diperlakukan sebagai terpencil, bahkan jika mereka lokal. Ini berarti Anda selalu siap untuk menghadapi semua masalah di atas (dan banyak lagi). Untuk proses lokal, ini memang menimbulkan sedikit overhead. Untuk membantu ini, ada banyak alat, kerangka kerja, perpustakaan, pola, dan idiom untuk menangani penanganan kesalahan dan pengawasan.
Anda belum menjelaskan bagaimana kerangka kerja RPC Anda bekerja secara khusus, dan bahasa atau pustaka apa yang Anda gunakan, tetapi saya memiliki kecurigaan kuat bahwa itu termasuk jenis "pura-pura jaringan tidak ada". Itu tidak bekerja. Tidak apa - apa untuk menghapus perbedaan antara panggilan lokal dan jarak jauh dengan memperlakukan semuanya sebagai panggilan jarak jauh . Melakukannya sebaliknya terlalu banyak abstrak: jaringan adalah bagian dari sistem Anda, jika Anda abstrak itu, Anda abstrak sesuatu yang benar - benar perlu Anda ketahui.
Sekarang, apakah Anda harus secara khusus menggunakan REST atau tidak, itu pertanyaan yang sama sekali berbeda. Seperti yang saya jelaskan di atas, web dirancang untuk REST dan SISA dirancang untuk web, sehingga dua lakukan masuk akal bersama-sama, tetapi Anda dapat menggunakan gaya arsitektur lain, jika Anda ingin. Tetapi setidaknya sebagian dari pertanyaan Anda adalah tentang "mengapa tidak RPC", dan saya menjelaskan alasan di atas, lebih tepatnya saya menjelaskan mengapa jenis RPC yang saya duga Anda gunakan dapat membuat Anda dalam masalah.