Kapan pendekatan RPC-ish lebih tepat daripada REST?


33

Setelah menonton ceramah ini tentang REST, Reuse, dan Serendipity oleh Steve Vinoski, saya bertanya-tanya apakah ada kasus bisnis dalam proyek greenfield untuk (XML-) pengaturan RPC-ish, yang REST tidak bisa selesaikan dengan cara yang lebih baik.

Beberapa Masalah RPC yang ia sebutkan:

  • Fokus pada bahasa (cocokkan sistem terdistribusi dengan bahasa, bukan sebaliknya)
  • "Jadikan terlihat lokal" (dan mengatasi kegagalan dan latensi sebagai pengecualian daripada aturan)
  • dimaksudkan untuk bahasa-independen, tetapi masih memiliki "panggilan fungsi" lintas bahasa sebagai bahan utama
  • Pelat boiler IDL
  • Ilusi keamanan tipe
  • dan beberapa lagi ...

Hanya untuk sedikit mendramatisirnya, beberapa hasil Google Instant untuk RPC vs REST:

RPC

BERISTIRAHAT

Jawaban:


20

Secara umum, RPC menawarkan jauh lebih banyak integrasi bahasa daripada REST. Seperti yang Anda sebutkan, ini hadir dengan sejumlah masalah dalam hal skala, penanganan kesalahan, keamanan jenis, dll., Terutama ketika sistem terdistribusi tunggal melibatkan banyak host yang menjalankan kode yang ditulis dalam berbagai bahasa. Namun, setelah memiliki sistem bisnis tertulis yang menggunakan RPC, REST, dan bahkan keduanya secara bersamaan, saya telah menemukan bahwa ada beberapa alasan bagus untuk memilih RPC daripada REST dalam kasus-kasus tertentu.

Inilah kasus di mana saya menemukan RPC lebih cocok:

  • Kopling ketat. Komponen (terdistribusi) dari sistem dirancang untuk bekerja bersama, dan mengubah yang satu kemungkinan akan berdampak pada yang lain. Kecil kemungkinan bahwa komponen harus disesuaikan untuk berkomunikasi dengan sistem lain di masa depan.
  • Komunikasi yang andal. Komponen akan berkomunikasi satu sama lain baik seluruhnya pada host yang sama atau pada jaringan yang tidak mungkin mengalami masalah latensi, kehilangan paket, dll. (Namun, ini masih berarti Anda perlu merancang sistem Anda untuk menangani kasus-kasus ini.)
  • Bahasa seragam. Semua (atau sebagian besar semua) komponen akan ditulis dalam satu bahasa. Kemungkinan komponen tambahan yang ditulis dalam bahasa yang berbeda tidak akan ditambahkan di masa mendatang.

Mengenai poin tentang IDL, dalam sistem REST Anda juga harus menulis kode yang mengubah data dalam permintaan dan tanggapan REST untuk representasi data internal apa pun yang Anda gunakan. Sumber IDL (dengan komentar yang baik) juga dapat berfungsi sebagai dokumentasi antarmuka, yang harus ditulis dan dikelola secara terpisah untuk REST API.

Tiga item di atas sering terjadi ketika Anda ingin membangun satu komponen sistem yang lebih besar. Dalam pengalaman saya, komponen-komponen ini seringkali merupakan komponen di mana subsistem mereka harus dapat gagal secara independen dan tidak menyebabkan kegagalan total dari subsistem lain atau seluruh komponen. Banyak sistem ditulis dalam bahasa Erlang untuk mencapai tujuan-tujuan ini juga, dan dalam beberapa kasus Erlang mungkin merupakan pilihan yang lebih baik daripada menulis sistem dalam bahasa lain dan menggunakan RPC hanya untuk mendapatkan manfaat ini.

Seperti kebanyakan masalah teknik, tidak ada solusi tunggal untuk masalah komunikasi antar-proses. Anda perlu melihat sistem yang Anda rancang dan membuat pilihan terbaik untuk kasus penggunaan Anda.


1

Ada beberapa keuntungan utama dari REST ketika produk ditingkatkan di pusat data dan Anda melakukan ketersediaan tinggi dan load balancing.

Namun, pikirkan proyek skala kecil. Membutuhkan layanan web yang akan memiliki beberapa ratus permintaan per jam? WCF menangani semua masalah transportasi. Memiliki antarmuka yang nyaman untuk mengirim objek di seluruh jaringan, dan memungkinkan koneksi jaringan untuk dikonfigurasi, dienkripsi, dan disertifikasi dengan nol pemrograman hanya dengan menggunakan file application.config.


1

Anda sebenarnya dapat memiliki keduanya. Plugin seperti RestRPC untuk Grails menyediakan anotasi yang akan mencegat panggilan ke metode Anda dan menanganinya dengan tenang sambil memungkinkan Anda untuk mendapatkan sebanyak yang Anda inginkan (yang akan sangat mirip RPC).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.