Saya yakin bahwa berita utama itu menimbulkan reaksi yang sehat - "Ya, itu mulai lagi ..." Tetapi biarkan saya menarik perhatian Anda selama 5-10 menit, dan saya akan berusaha untuk tidak menipu harapan.
Struktur artikel akan menjadi sebagai berikut: pernyataan stereotip diambil dan "sifat" dari munculnya stereotip ini terungkap. Saya harap ini memungkinkan Anda untuk melihat pilihan paradigma pertukaran data dalam proyek Anda dari sudut pandang baru.
Untuk memperjelas apa itu RPC, saya mengusulkan untuk mempertimbangkan standar JSON-RPC 2.0 . Tidak ada kejelasan dengan REST. Dan seharusnya tidak. Semua yang perlu Anda ketahui tentang REST - tidak bisa dibedakan dari HTTP .
Permintaan RPC lebih cepat dan lebih efisien karena memungkinkan permintaan batch.
Intinya adalah bahwa dalam RPC dimungkinkan untuk melakukan panggilan ke beberapa prosedur dalam satu permintaan. Misalnya, buat pengguna, tambahkan avatar padanya dan permintaan yang sama tandatangani dia pada beberapa topik. Hanya satu permintaan, dan seberapa bagus!
Memang, jika Anda hanya memiliki satu simpul backend, ini akan tampak lebih cepat dengan permintaan batch. Karena tiga permintaan REST akan membutuhkan sumber daya tiga kali lebih banyak dari satu node untuk membuat koneksi.
Harap dicatat bahwa permintaan pertama dalam kasus REST harus mengembalikan ID pengguna untuk permintaan berikutnya. Yang juga berdampak negatif pada hasil keseluruhan.
Tetapi infrastruktur seperti itu dapat ditemukan, mungkin, dalam solusi internal dan Enterprise. Sebagai upaya terakhir, dalam proyek WEB kecil. Tetapi solusi WEB lengkap, dan juga disebut HighLoad, tidak boleh dibangun seperti ini. Infrastruktur mereka harus memenuhi kriteria ketersediaan tinggi dan beban kerja. Dan gambarnya berubah.
Hijau menunjukkan saluran aktivitas infrastruktur dalam skenario yang sama. Perhatikan bagaimana perilaku RPC sekarang. Permintaan menggunakan infrastruktur hanya satu bahu dari penyeimbang ke backend. Meskipun REST masih kalah dalam permintaan pertama, tetapi mengganti waktu yang hilang menggunakan seluruh infrastruktur.
Cukup dengan memasukkan dalam naskah bukan dua permintaan untuk pengayaan, tetapi, katakanlah, lima atau sepuluh ... dan jawaban untuk pertanyaan "siapa yang menang sekarang?" Menjadi tidak jelas.
Saya mengusulkan untuk melihat masalah yang lebih luas. Diagram menunjukkan bagaimana saluran infrastruktur digunakan, tetapi infrastruktur tidak terbatas pada saluran. Komponen penting dari infrastruktur yang sarat muatan adalah cache. Mari kita ambil beberapa artefak pengguna sekarang. Beberapa kali. Katakan 32 kali.
Lihat bagaimana infrastruktur pada RPC telah tampak "pulih" untuk memenuhi tuntutan beban tinggi. Masalahnya adalah bahwa REST menggunakan kekuatan penuh dari protokol HTTP, tidak seperti RPC. Dalam diagram di atas, kekuatan ini diwujudkan melalui metode permintaan - GET.
Metode HTTP, antara lain, memiliki strategi caching. Anda dapat mengenal mereka di dokumentasi HTTP . Untuk RPC, permintaan POST yang tidak dianggap sebagai idempoten digunakan, yaitu pengulangan berulang dari permintaan POST yang sama dapat mengembalikan hasil yang berbeda (misalnya, setelah setiap komentar dikirim, salinan lain dari komentar ini akan muncul) ( sumber ).
Akibatnya, RPC tidak dapat menggunakan cache infrastruktur secara efisien. Ini mengarah pada fakta bahwa Anda harus "mengimpor" cache perangkat lunak. Diagram menunjukkan Redis dalam peran ini. Soft cache, pada gilirannya, mengharuskan pengembang lapisan kode tambahan dan perubahan signifikan dalam arsitektur.
Sekarang mari kita menghitung berapa banyak permintaan “melahirkan” REST dan RPC dalam infrastruktur yang sedang dipertimbangkan?
[*] dalam kasus terbaik (jika cache lokal digunakan) 1 permintaan (satu!), dalam 32 permintaan terburuk yang masuk.
Dibandingkan dengan skema pertama, perbedaannya mencolok. Kemenangan REST sekarang jelas. Tetapi saya mengusulkan untuk tidak berhenti di situ. Infrastruktur yang dikembangkan termasuk CDN. Seringkali, ia juga memecahkan masalah melawan serangan DDoS dan DoS. Kami mendapatkan:
Di sini untuk RPC, semuanya menjadi sangat menyedihkan. RPC tidak dapat mendelegasikan pekerjaan dengan memuat CDN. Seseorang hanya dapat mengandalkan sistem untuk melawan serangan.
Apakah mungkin untuk mengakhiri ini? Dan lagi, tidak. Metode HTTP, seperti yang disebutkan di atas, memiliki "keajaiban" sendiri. Dan untuk alasan yang baik, metode GET benar-benar digunakan di Internet. Harap dicatat bahwa metode ini dapat mengakses bagian dari konten, dapat mengatur kondisi yang dapat menafsirkan elemen infrastruktur sebelum mentransfer kontrol ke kode Anda, dll. Semua ini memungkinkan Anda untuk membuat infrastruktur yang fleksibel dan dapat dikelola yang dapat mencerna aliran permintaan yang sangat besar. Dan di RPC, metode ini ... diabaikan.
Jadi mengapa mitos ini begitu gigih sehingga permintaan batch (RPC) lebih cepat? Secara pribadi, saya merasa bahwa sebagian besar proyek tidak mencapai tingkat pengembangan ketika REST mampu menunjukkan kekuatannya. Selain itu, dalam proyek-proyek kecil, ia lebih cenderung menunjukkan kelemahannya.
Pilihan REST atau RPC bukanlah pilihan sukarela individu dalam proyek. Pilihan ini harus memenuhi persyaratan proyek. Jika proyek mampu keluar dari REST semua yang benar-benar bisa, dan itu benar-benar diperlukan, maka REST akan menjadi pilihan yang sangat baik.
Tetapi jika untuk mendapatkan semua keuntungan REST, Anda perlu menyewa devops untuk segera meningkatkan infrastruktur, administrator untuk mengelola infrastruktur, arsitek untuk merancang semua lapisan layanan WEB ... dan proyek akan menjual tiga bungkus margarin per hari ... Saya akan berhenti di RPC sejak itu protokol ini lebih bermanfaat. Ini tidak memerlukan pengetahuan mendalam tentang operasi cache dan infrastruktur, tetapi memfokuskan pengembang pada panggilan sederhana dan dapat dimengerti ke prosedur yang diperlukan. Bisnis akan senang.
Permintaan RPC lebih dapat diandalkan karena mereka dapat menjalankan permintaan batch dalam satu transaksi
Properti RPC ini merupakan nilai tambah pasti, karena mudah untuk menjaga database dalam keadaan konsisten. Tetapi dengan REST, semuanya lebih rumit. Permintaan dapat tiba secara tidak konsisten pada berbagai node backend.
"Kelemahan" REST ini adalah sisi lain dari kelebihannya yang dijelaskan di atas - kemampuan untuk menggunakan semua sumber daya infrastruktur secara efektif. Jika infrastruktur dirancang dengan buruk, dan bahkan lebih lagi jika arsitektur proyek dan database khususnya dirancang dengan buruk, maka ini benar-benar menyebalkan.
Tetapi apakah permintaan batch dapat diandalkan seperti kelihatannya? Mari kita lihat kasusnya: membuat pengguna, memperkaya profilnya dengan beberapa deskripsi dan mengiriminya SMS dengan rahasia untuk menyelesaikan pendaftaran. Yaitu tiga panggilan dalam satu permintaan batch.
Mari kita pertimbangkan skemanya. Ini menyajikan infrastruktur dengan elemen ketersediaan tinggi. Ada dua saluran komunikasi independen dengan gateway SMS. Tapi ... apa yang kita lihat? Saat mengirim SMS, kesalahan 503 terjadi - layanan sementara tidak tersedia. Karena mengirim SMS dikemas dalam permintaan batch, maka seluruh permintaan harus dibatalkan. Tindakan dalam DBMS dibatalkan. Klien menerima kesalahan.
Upaya selanjutnya adalah lotere. Entah permintaan pergi ke simpul yang sama lagi dan mengembalikan kesalahan, atau Anda beruntung dan itu akan dieksekusi. Tetapi yang utama adalah bahwa setidaknya sekali infrastruktur kita telah bekerja dengan sia-sia. Ada beban, tapi tidak ada untung.
Nah, mari kita bayangkan bahwa kita tegang (!) Dan memikirkan opsi di mana permintaan dapat diselesaikan sebagian. Dan sisanya, kita akan mencoba lagi untuk memenuhi setelah beberapa interval waktu (Yang? Tentukan bagian depan?). Tapi lotere tetap ada. Permintaan untuk mengirim SMS dengan probabilitas 50/50 akan gagal lagi.
Setuju, di sisi klien, layanan ini tampaknya tidak dapat diandalkan seperti yang kita inginkan ... tetapi bagaimana dengan REST?
REST menggunakan sihir HTTP lagi, tetapi sekarang dengan kode respons. Jika kesalahan 503 terjadi pada gateway SMS, backend menyiarkan kesalahan ini ke penyeimbang. Penyeimbang menerima kesalahan ini, dan tanpa memutus koneksi dengan klien, mengirimkan permintaan ke node lain yang berhasil memproses permintaan tersebut. Yaitu klien menerima hasil yang diharapkan, dan infrastruktur mengkonfirmasi peringkat tinggi "sangat mudah diakses". Pengguna itu senang.
Dan lagi, ini belum semuanya. Penyeimbang tidak hanya menerima kode respons 503. Disarankan untuk memberikan kode ini dengan tajuk "Coba Lagi" ketika menjawab. Tajuk menjelaskan kepada penyeimbang bahwa Anda tidak boleh mengganggu simpul ini pada rute ini untuk waktu tertentu. Dan permintaan pengiriman SMS berikut ini akan segera dikirim ke node yang tidak memiliki masalah dengan SMS gateway.
Seperti yang bisa kita lihat, keandalan JSON-RPC terlalu dibesar-besarkan. Memang, lebih mudah untuk mengatur konsistensi database. Tetapi korban, dalam hal ini, akan menjadi keandalan sistem secara keseluruhan.
Kesimpulannya sebagian besar mirip dengan yang sebelumnya. Ketika infrastrukturnya sederhana, kejelasan JSON-RPC tidak diragukan lagi kelebihannya. Jika suatu proyek melibatkan ketersediaan tinggi dengan beban tinggi, REST terlihat seperti solusi yang lebih akurat, meskipun lebih kompleks.
Ambang entri REST di bawah
Saya pikir analisis di atas, menghilangkan prasangka stereotip tentang RPC, dengan jelas menunjukkan bahwa ambang batas untuk memasuki REST tidak diragukan lagi lebih tinggi daripada di RPC. Hal ini disebabkan oleh kebutuhan akan pemahaman yang mendalam tentang HTTP, serta kebutuhan untuk memiliki pengetahuan yang cukup tentang elemen infrastruktur yang ada yang dapat dan harus digunakan dalam proyek WEB.
Jadi mengapa banyak orang berpikir bahwa REST akan lebih mudah? Pendapat pribadi saya adalah bahwa kesederhanaan yang tampak ini berasal dari REST yang memanifestasikan diri. Yaitu REST bukan protokol, tetapi sebuah konsep ... REST tidak memiliki standar, ada beberapa rekomendasi ... REST tidak lebih rumit dari HTTP. Kebebasan dan anarki yang tampak menarik "seniman bebas".
Tidak diragukan lagi, REST tidak lebih rumit dari HTTP. Tetapi HTTP sendiri adalah protokol yang dirancang dengan baik yang telah terbukti selama beberapa dekade. Jika tidak ada pemahaman mendalam tentang HTTP itu sendiri, maka REST tidak dapat dinilai.
Tetapi tentang RPC - Anda bisa. Sudah cukup untuk mengambil spesifikasinya. Jadi, apakah Anda memerlukan JSON-RPC yang bodoh ? Atau apakah REST itu licik? Terserah kamu.
Saya sungguh berharap bahwa saya tidak membuang waktu Anda dengan sia-sia.