Perbedaan layanan web antara REST dan RPC


108

Saya memiliki layanan web yang menerima parameter JSON dan memiliki URL khusus untuk metode, misalnya:

http://IP:PORT/API/getAllData?p={JSON}

Ini jelas bukan REST karena bukan tanpa kewarganegaraan. Ini memperhitungkan cookie dan memiliki sesinya sendiri.

Apakah RPC? Apa perbedaan antara RPC dan REST?


1
Mengapa penting jika REST atau RPC? Apa alasanmu bertanya?
Bogdan

5
Layanan ini bukan milik saya dan menyatakan bahwa REST tetapi tampaknya tidak. Saya ingin mencari tahu apakah saya salah tentang itu bukan REST.
Mazmart

115
Pengetahuan @Bogdan adalah alasannya.
Tuan

1
@Bogdan -Aku takut permulaan ironi dan lubang kelinci rekursif, tapi kenapa kamu bertanya mengapa dia bertanya?
glowkeeper

@glowkeeper: Saya ingin memahami konteks pertanyaan, untuk mengetahui cara merumuskan jawaban dengan lebih baik.
Bogdan

Jawaban:


75

Anda tidak dapat membuat pemisahan yang jelas antara REST atau RPC hanya dengan melihat apa yang Anda posting.

Salah satu kendala REST adalah harus tanpa kewarganegaraan. Jika Anda memiliki sesi maka Anda memiliki status sehingga Anda tidak dapat memanggil layanan Anda RESTful.

Fakta bahwa Anda memiliki tindakan di URL Anda (yaitu getAllData) merupakan indikasi terhadap RPC. Di REST Anda bertukar representasi dan operasi yang Anda lakukan ditentukan oleh kata kerja HTTP. Selain itu, di REST, Negosiasi konten tidak dilakukan dengan ?p={JSON}parameter.

Tidak tahu apakah layanan Anda RPC, tetapi tidak RESTful. Anda dapat mempelajari perbedaannya secara online, berikut adalah artikel untuk Anda mulai: Membongkar Mitos RPC & REST . Anda lebih tahu apa yang ada di dalam layanan Anda jadi bandingkan fungsinya dengan apa itu RPC dan buat kesimpulan Anda sendiri.


so RESTful berarti mematuhi semua standar selain REST ketika mungkin memilih untuk tidak mematuhi standar ?.
Mazmart

5
@Mazmart: REST adalah seperangkat pedoman dan batasan. Ini bukanlah spesifikasi yang dapat diterapkan dan saat mereka mengklaim memiliki layanan RESTful. Dari apa yang saya perhatikan, sebagian besar waktu orang merujuk pada apa pun yang bukan SOAP sebagai REST, padahal sebenarnya hanya semacam RPC lainnya.
Bogdan

131

Pertimbangkan contoh API HTTP berikut yang mencontohkan pesanan yang ditempatkan di restoran.

  • The RPC API berpikir dalam hal "kata kerja", mengekspos fungsi restoran sebagai panggilan fungsi yang menerima parameter, dan memanggil fungsi-fungsi ini melalui HTTP kata kerja yang tampaknya paling tepat - 'mendapatkan' untuk query, dan sebagainya, tapi nama dari kata kerja tersebut murni insidental dan tidak memiliki kaitan nyata dengan fungsionalitas sebenarnya, karena Anda memanggil URL yang berbeda setiap kali . Kode pengembalian adalah kode tangan, dan bagian dari kontrak layanan.
  • Sebaliknya, REST API memodelkan berbagai entitas dalam domain masalah sebagai sumber daya, dan menggunakan kata kerja HTTP untuk mewakili transaksi terhadap sumber daya ini - POST untuk dibuat, PUT untuk diperbarui, dan GET untuk dibaca. Semua kata kerja ini, yang dipanggil di URL yang sama , menyediakan fungsi yang berbeda. Kode pengembalian HTTP umum digunakan untuk menyampaikan status permintaan.

Menempatkan Pesanan:

Mengambil Pesanan:

Memperbarui Pesanan:

Contoh diambil dari sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc


34
Terakhir beberapa contoh URL.
Fabian Picone

4
Saya tidak setuju dengan apa yang Anda katakan tentang URL. Anda dapat memiliki semua panggilan RPC di URL yang sama dan REST di URL yang berbeda. Anda hanya menunjukkan satu sisi koin.
basickarl

Apa yang Anda gambarkan di sini bukanlah REST - REST adalah pola arsitektur. Apa yang Anda gambarkan adalah REST over HTTP, yang dipikirkan kebanyakan orang ketika mereka berbicara tentang REST.
d4nyll

40

Seperti yang dikatakan orang lain, perbedaan utama adalah bahwa REST berpusat pada kata benda dan RPC berpusat pada kata kerja. Saya hanya ingin menyertakan tabel contoh yang jelas ini yang menunjukkan bahwa:

--------------------------- + ---------------------- --------------- + --------------------------
  Operasi                  | RPC (operasi)                      | REST (sumber daya)
--------------------------- + ---------------------- --------------- + --------------------------
 Daftar | POSTING / daftar | POST / orang           
--------------------------- + ---------------------- --------------- + --------------------------
 Mengundurkan diri | POSTING / mundur | HAPUS / orang / 1234    
--------------------------- + ---------------------- --------------- + --------------------------
 Baca orang | GET / readPerson? Personid = 1234 | GET / orang / 1234       
--------------------------- + ---------------------- --------------- + --------------------------
 Membaca daftar item orang | GET / readUsersItemsList? Userid = 1234 | DAPATKAN / orang / 1234 / item
--------------------------- + ---------------------- --------------- + --------------------------
 Tambahkan item ke daftar orang | POST / addItemToUsersItemsList | POST / orang / 1234 / item
--------------------------- + ---------------------- --------------- + --------------------------
 Perbarui item | POST / modifikasikanItem | PUT / item / 456          
--------------------------- + ---------------------- --------------- + --------------------------
 Hapus item | POST / removeItem? ItemId = 456 | HAPUS / item / 456       
--------------------------- + ---------------------- --------------- + --------------------------

Catatan

  • Seperti yang ditunjukkan tabel, REST cenderung menggunakan parameter jalur URL untuk mengidentifikasi sumber daya tertentu
    (misalnya GET /persons/1234), sedangkan RPC cenderung menggunakan parameter kueri untuk input fungsi
    (misalnya GET /readPerson?personid=1234).
  • Tidak ditampilkan dalam tabel bagaimana REST API akan menangani pemfilteran, yang biasanya melibatkan parameter kueri (misalnya GET /persons?height=tall).
  • Juga tidak ditampilkan bagaimana dengan sistem mana pun, ketika Anda melakukan operasi buat / perbarui, data tambahan mungkin diteruskan melalui badan pesan (misalnya ketika Anda melakukannya POST /signupatau POST /persons, Anda menyertakan data yang menjelaskan orang baru).
  • Tentu saja, tidak satu pun dari ini yang ditetapkan, tetapi ini memberi Anda gambaran tentang apa yang mungkin Anda temui dan bagaimana Anda mungkin ingin mengatur API Anda sendiri untuk konsistensi. Untuk diskusi lebih lanjut tentang desain REST URL, lihat pertanyaan ini .

32

Ini adalah RPC menggunakan http . Implementasi REST yang benar harus berbeda dari RPC. Untuk memiliki logika untuk memproses data, seperti metode / fungsi, adalah RPC. getAllData () adalah metode cerdas. REST tidak dapat memiliki kecerdasan, itu harus berupa data dump yang dapat dipertanyakan oleh kecerdasan eksternal .

Sebagian besar implementasi yang saya lihat akhir-akhir ini adalah RPC tetapi banyak yang secara keliru menyebutnya sebagai REST. REST dengan HTTP adalah penyelamat dan SOAP dengan XML penjahatnya. Jadi kebingungan Anda dibenarkan dan Anda benar, itu bukan REST.

Protokol http tidak membuat implementasi REST. Baik REST (GET, POST, PUT, PATCH, DELETE) dan RPC (GET + POST) dapat dikembangkan melalui HTTP (misalnya: melalui proyek API web di studio visual).

Baik, tapi apa itu REST? Model kematangan Richardson diberikan di bawah ini (diringkas). Hanya level 3 yang RESTful.

  • Level 0: POST Http
  • Level 1: setiap sumber daya / entitas memiliki URI (tetapi masih hanya POST)
  • Level 2: POST dan GET dapat digunakan
  • Level 3 (RESTful): Menggunakan HATEOAS (hyper media links) atau dengan kata lain self exploratory links

misal: level 3 (HATEOAS):

  1. Tautan menyatakan objek ini dapat diperbarui dengan cara ini, dan ditambahkan dengan cara ini.

  2. Tautan menyatakan objek ini hanya dapat dibaca dan begitulah cara kami melakukannya.

    Jelasnya, mengirim data saja tidak cukup untuk menjadi REST, tapi bagaimana cara query data, harus disebutkan juga. Tapi sekali lagi, mengapa 4 langkah? Mengapa tidak hanya Langkah 4 dan menyebutnya REST? Richardson baru saja memberi kami pendekatan langkah demi langkah untuk sampai ke sana, itu saja.

Anda telah membangun situs web yang dapat digunakan oleh manusia. Tetapi dapatkah Anda juga membangun situs web yang dapat digunakan oleh mesin? Di situlah masa depan terletak, dan Layanan Web RESTful menunjukkan kepada Anda bagaimana melakukannya.

PS: REST sangat populer begitu juga pengujian otomatis tetapi ketika datang ke contoh dunia nyata .. yah ..


1
Paragraf pertama menjelaskan perbedaannya dengan cara yang sangat sederhana dan lugas. Miliki +1 saya :)
Nikolas Charalambidis

15

REST paling baik dijelaskan untuk bekerja dengan sumber daya, sedangkan RPC lebih banyak tentang tindakan.

REST adalah singkatan dari Representational State Transfer. Ini adalah cara sederhana untuk mengatur interaksi antara sistem independen. Aplikasi RESTful biasanya menggunakan permintaan HTTP untuk mengirim data (membuat dan / atau memperbarui), membaca data (misalnya membuat kueri), dan menghapus data. Jadi, REST dapat menggunakan HTTP untuk keempat operasi CRUD (Buat / Baca / Perbarui / Hapus).

RPC pada dasarnya digunakan untuk berkomunikasi di berbagai modul untuk melayani permintaan pengguna. misalnya Dalam openstack seperti bagaimana nova, glance dan neutron bekerja sama saat mem-boot mesin virtual.


4

Saya akan membantah demikian:

Apakah entitas saya memegang / memiliki data? Kemudian RPC: ini adalah salinan dari beberapa data saya, manipulasi salinan data yang saya kirimkan kepada Anda dan kembalikan kepada saya salinan hasil Anda.

Apakah entitas yang disebut memegang / memiliki data? Kemudian REST: baik (1) tunjukkan salinan beberapa data Anda atau (2) manipulasi beberapa data Anda.

Pada akhirnya, ini adalah tentang "sisi" mana dari tindakan yang memiliki / menyimpan data. Dan ya, Anda dapat menggunakan verbiage REST untuk berbicara dengan sistem berbasis RPC, tetapi Anda masih akan melakukan aktivitas RPC saat melakukannya.

Contoh 1: Saya memiliki objek yang berkomunikasi ke penyimpanan database relasional (atau jenis penyimpanan data lainnya) melalui DAO. Masuk akal untuk menggunakan gaya REST untuk interaksi antara objek saya dan objek akses data yang dapat ada sebagai API. Entitas saya tidak memiliki / menyimpan data, database relasional (atau penyimpanan data non-relasional) memilikinya.

Contoh 2: Saya perlu melakukan banyak matematika yang rumit. Saya tidak ingin memuat banyak metode matematika ke dalam objek saya, saya hanya ingin meneruskan beberapa nilai ke hal lain yang dapat melakukan semua jenis matematika, dan mendapatkan hasil. Kemudian gaya RPC masuk akal, karena objek / entitas matematika akan mengekspos ke objek saya sejumlah operasi. Perhatikan bahwa semua metode ini mungkin diekspos sebagai API individual dan saya mungkin memanggil salah satunya dengan GET. Saya bahkan dapat mengklaim ini RESTful karena saya menelepon melalui HTTP GET tetapi sebenarnya di balik penutup itu adalah RPC. Entitas saya memiliki / menyimpan data, entitas jarak jauh hanya melakukan manipulasi pada salinan data yang saya kirimkan.


3

Melalui HTTP mereka berdua akhirnya hanya menjadi HttpRequestobjek dan mereka berdua mengharapkan sebuah HttpResponseobjek kembali. Saya pikir seseorang dapat melanjutkan pengkodean dengan deskripsi itu dan mengkhawatirkan hal lain.


2

Ada banyak jawaban bagus di sini. Saya masih akan merujuk Anda ke blog google ini karena ini sangat bagus dalam membahas perbedaan antara RPC & REST dan menangkap sesuatu yang tidak saya baca di salah satu jawaban di sini.

Saya akan mengutip satu paragraf dari tautan yang sama yang menarik bagi saya:

REST sendiri adalah deskripsi prinsip desain yang mendukung HTTP dan web di seluruh dunia. Tetapi karena HTTP adalah satu-satunya REST API yang penting secara komersial, sebagian besar kita dapat menghindari diskusi REST dan hanya fokus pada HTTP. Substitusi ini berguna karena ada banyak kebingungan dan variabilitas dalam arti REST dalam konteks API, tetapi ada kejelasan dan kesepakatan yang jauh lebih besar tentang apa itu HTTP itu sendiri. Model HTTP adalah kebalikan sempurna dari model RPC — dalam model RPC, unit yang dapat dialamatkan adalah prosedur, dan entitas domain masalah tersembunyi di balik prosedur. Dalam model HTTP, unit yang dapat dialamatkan adalah entitas itu sendiri dan perilaku sistem disembunyikan di balik entitas sebagai efek samping dari membuat, memperbarui, atau menghapusnya.


1

Inilah cara saya memahami dan menggunakannya dalam berbagai kasus penggunaan:

Contoh: Manajemen Restoran

use-case untuk REST : manajemen pesanan

- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123

Untuk manajemen sumber daya, REST bersih. Satu titik akhir dengan tindakan yang telah ditentukan sebelumnya. Ini dapat dilihat cara untuk mengekspos DB (Sql atau NoSql) atau instance kelas ke dunia.

Contoh Implementasi:

class order:
    on_get(self, req, resp): doThis.
    on_patch(self, req, resp): doThat.

Contoh Kerangka: Falcon untuk python.

use-case untuk RPC : manajemen operasi

- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123

Untuk pekerjaan analitis, operasional, non-responsif, non-representatif, berbasis tindakan, RPC bekerja lebih baik dan sangat wajar untuk berpikir fungsional.

Contoh Implementasi:

@route('/operation/cook/<orderId>')
def cook(orderId): doThis.

@route('/operation/serve/<orderId>')
def serve(orderId): doThat.

Contoh Kerangka Kerja: Flask untuk python

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.