REST vs JSON-RPC? [Tutup]


251

Saya mencoba memilih antara REST dan JSON-RPC untuk mengembangkan API untuk aplikasi web. Bagaimana mereka membandingkan?

Pembaruan 2015: Saya menemukan REST lebih mudah untuk dikembangkan dan digunakan untuk API yang disajikan di Web / HTTP, karena protokol HTTP yang ada dan matang yang dipahami oleh klien dan server dapat dimanfaatkan oleh API. Misalnya kode respons, tajuk, kueri, badan pos, caching, dan banyak fitur lainnya dapat digunakan oleh API tanpa upaya atau pengaturan tambahan.


29
REST jelas merupakan jawaban populer saat ini. Saya tidak yakin bahwa itu selalu jawaban yang tepat. Mungkin ada ketidakcocokan impedansi antara REST API berbasis sumber daya dan domain masalah yang secara inheren berbasis tugas atau alur kerja. Jika Anda menemukan bahwa Anda harus melakukan berbagai jenis PATCH ke sumber daya yang sama atau bahwa tugas tertentu tidak memetakan ke sumber daya tertentu, maka Anda harus mulai membengkokkan paradigma REST. Apakah Anda menggunakan tindakan / perintah sebagai sumber daya. Apakah Anda membedakan jenis perintah di header Tipe Konten sebagai parameter? Tidak yakin ada jawaban satu ukuran untuk semua.
Landon Poch

27
JSON-RPC sederhana dan konsisten, senang digunakan.
dnault

1
Agustus 2015, saya telah mengimplementasikan kedua klien & server menggunakan REST, 2 hari pertama saya belajar kemudian saya mengerti mengapa itu populer. Itu benar-benar kegembiraan setelah aplikasi kecil dibuat, klien benar-benar tidak memiliki pekerjaan untuk mengingat berbagai jalur url, server pada node.js & klien dalam javascript berbagi struktur yang sama (jalur url) untuk berkomunikasi. Wow! itu sangat cepat, produk dikirim hanya dalam 15 hari, bahkan menulis dari awal. REST adalah jalannya. Juga catat bahwa Populer Apache CouchDB menggunakan REST, basis data yang hebat, sangat bangga mereka lakukan di REST juga. Secara sederhana, REST is RIGHT (benar) dengan antarmuka yang bersih.
Manohar Reddy Poreddy

6
Itu tergantung pada kendala yang Anda miliki atau tujuan utama Anda. Misalnya, jika kinerja adalah aspek utama cara Anda untuk pergi adalah JSON-RPC (mis. Komputasi Kinerja Tinggi). Jika tujuan utama Anda adalah menjadi agnostik sehingga menyediakan antarmuka umum untuk ditafsirkan oleh orang lain, cara Anda untuk pergi adalah REST. Jika Anda ingin kedua tujuan, Anda harus memasukkan kedua protokol. Kebutuhan Anda menentukan solusinya.
Stathis Andronikos

@StathisAndronikos Anda benar, tujuan utama saya adalah kemudahan penggunaan dan kinerja yang baik untuk aplikasi web (bukan HPC).
Ali Shakiba

Jawaban:


221

Masalah mendasar dengan RPC adalah kopling. Klien RPC menjadi sangat dekat dengan implementasi layanan dalam beberapa cara dan menjadi sangat sulit untuk mengubah implementasi layanan tanpa melanggar klien:

  • Klien diminta untuk mengetahui nama prosedur;
  • Parameter prosedur memesan, jenis, dan menghitung hal-hal. Tidak mudah untuk mengubah tanda tangan prosedur (jumlah argumen, urutan argumen, jenis argumen dll ...) di sisi server tanpa melanggar implementasi klien;
  • Gaya RPC tidak memaparkan apa pun selain prosedur titik akhir + argumen prosedur. Tidak mungkin bagi klien untuk menentukan apa yang dapat dilakukan selanjutnya.

Di sisi lain dalam gaya REST sangat mudah untuk memandu klien dengan memasukkan informasi kontrol dalam representasi (HTTP header + representasi). Sebagai contoh:

  • Adalah mungkin (dan sebenarnya wajib) untuk menyematkan tautan yang dianotasi dengan tipe hubungan tautan yang menyampaikan makna URI ini;
  • Implementasi klien tidak perlu bergantung pada nama prosedur dan argumen tertentu. Sebaliknya, klien bergantung pada format pesan. Ini menciptakan kemungkinan untuk menggunakan perpustakaan yang sudah diterapkan untuk format media tertentu (mis. Atom, HTML, Collection + JSON, HAL dll ...)
  • Dimungkinkan untuk dengan mudah mengubah URI tanpa melanggar klien sejauh mereka hanya bergantung pada hubungan tautan terdaftar (atau spesifik domain);
  • Dimungkinkan untuk menanamkan struktur seperti bentuk dalam representasi, memberi klien kemungkinan untuk mengekspos deskripsi ini sebagai kemampuan UI jika pengguna akhir adalah manusia;
  • Dukungan untuk caching adalah keuntungan tambahan;
  • Kode status standar;

Ada banyak perbedaan dan kelebihan di sisi REST.


20
Apa yang Anda maksud dengan "itu wajib untuk menyematkan tautan beranotasi dengan tipe hubungan tautan yang menyampaikan makna .."?
pjz

129
"Klien harus mengetahui nama prosedur" - itu bukan argumen karena dengan REST nama ini di-hardcode ke URI alih-alih diteruskan sebagai parameter. Kalau tidak, server tidak akan tahu metode mana yang harus dijalankan.
Centurion

44
"Tidak mudah untuk mengubah tanda tangan prosedur ... di sisi server tanpa melanggar implementasi klien", ini juga masih bisa diperdebatkan. Baik REST dan JSON-RPC bukan SOAP dan tidak memiliki WSDL yang menjelaskan layanan web yang ada dan jenisnya sehingga dapat digunakan untuk perubahan dinamis di sisi klien. Jadi, jika Anda mengubah layanan web, Anda harus mengubah klien. Kalau tidak, Anda harus menggunakan SABUN.
Centurion

64
Saya telah memberi kode kepada dosen aplikasi tetapi belum melihat layanan web yang fleksibel. Jika Anda mengubah backend dan layanan web dari klien selalu perlu di refactored / diperbarui agar sesuai dengan persyaratan baru. Dan saya telah menyebutkan SOAP dan karena ia memiliki sesuatu yang memberikan fleksibilitas, seperti WSDL, sehingga Anda dapat mengotomatisasi sesuatu dan memiliki lebih banyak fleksibilitas karena Anda bisa mendapatkan info tentang set hasil, tipe data, dan layanan web yang tersedia. REST dan yang lainnya tidak memilikinya sama sekali. Begitu juga REST, atau JSON-RPC, atau jenis layanan web lainnya tidak akan memberikan Anda keajaiban yang akan menghilangkan kebutuhan untuk memperbarui klien secara manual.
Centurion

15
Bagi saya, tim saya saat ini dan tim sebelumnya, layanan web RESTful adalah untuk aplikasi jenis CRUD. Mengenai "Apakah kita menulis ulang browser setiap kali ada perubahan di server?" - tidak, karena browser hanyalah pelaksana HTTP, mereka tidak ada hubungannya dengan logika bisnis, yang perlu diimplementasikan oleh program klien (perlihatkan layar, lakukan hal-hal terkait). Sepertinya kami telah memulai perang api, tetapi secara umum saya berharap saya akan memiliki sumber solid lain untuk layanan web RESTfull dengan aliran penggunaan praktis, dengan fleksibilitas magis yang Anda maksudkan. Sementara itu banyak pernyataan yang terlalu kabur.
Centurion

163

Saya telah mengeksplorasi masalah ini secara terperinci dan memutuskan bahwa REST murni terlalu membatasi, dan RPC adalah yang terbaik, meskipun sebagian besar aplikasi saya adalah aplikasi CRUD. Jika Anda tetap pada REST, Anda akhirnya akan menggaruk-garuk kepala Anda bertanya-tanya bagaimana Anda dapat dengan mudah menambahkan metode lain yang diperlukan untuk API Anda untuk beberapa tujuan khusus. Dalam banyak kasus, satu-satunya cara untuk melakukannya dengan REST adalah membuat pengontrol lain untuk itu, yang mungkin terlalu menyulitkan program Anda.

Jika Anda memutuskan RPC, satu-satunya perbedaan adalah bahwa Anda secara eksplisit menetapkan kata kerja sebagai bagian dari URI, yang jelas, konsisten, kurang buggy, dan benar-benar tidak ada masalah. Terutama jika Anda membuat aplikasi yang melampaui CRUD sederhana, RPC adalah satu-satunya cara untuk melangkah. Saya memiliki masalah lain dengan purest RESTful: HTTP POST, GET, PUT, DELETE memiliki makna tertentu dalam HTTP yang telah ditumbangkan oleh REST ke dalam arti hal-hal lain, hanya karena mereka cocok sebagian besar waktu - tetapi tidak semua waktu.

Dalam pemrograman, saya sudah lama menemukan bahwa mencoba menggunakan satu hal berarti dua hal akan muncul kapan saja dan menggigit Anda. Saya suka memiliki kemampuan untuk menggunakan POST untuk hampir setiap tindakan, karena memberikan kebebasan untuk mengirim dan menerima data sebagaimana metode Anda perlu lakukan. Anda tidak bisa memasukkan seluruh dunia ke dalam CRUD.


30
Jawaban ini menunjukkan kesalahpahaman yang terlalu umum tentang apa sebenarnya REST. REST jelas bukan hanya pemetaan metode CRUD ke HTTP. Gagasan bahwa itu adalah masalah untuk "menambahkan metode lain" dengan jelas menunjukkan bahwa REST disalahpahami sebagai RPC melalui HTTP, yang tidak sama sekali. Coba baca blog Roy Fieldings atau disertasinya - Google akan membantu Anda menemukannya - Anda sama sekali tidak menggambarkan REST dalam jawaban Anda.
nepdev

68
Saya orang yang sangat praktis. Semua deskripsi REST yang telah saya baca dengan jelas mulai dengan pemetaan metode CRUD ke HTTP. Lebih banyak diizinkan untuk ditambahkan secara teoritis, tetapi dalam praktiknya, tidak. Sebagai contoh, saya baru-baru ini ingin mengimplementasikan PATCH untuk perangkat Android, tetapi menemukan bahwa Android tidak mengizinkan PATCH, jadi saya menggunakan POST dengan tindakan yang didefinisikan secara eksplisit untuk efek di URI. Pada dasarnya, REST murni tidak akan melakukan pekerjaan yang saya butuhkan, jadi saya menggunakan yang berfungsi.
Bruce Patin

4
Jadi @BrucePatin, dalam "REST" versi Anda, Anda memiliki pengontrol dengan empat metode publik yang memetakan 1 ke 1 dengan GET | PUT | POST | DELETE? Beberapa kerangka kerja melakukan itu tetapi itu bukan REST. Kata kerja HTTP membuat pernyataan abstrak yang tidak jelas tentang semantik dari permintaan yang diberikan. Anda harus memetakan titik akhir Anda ke dalam kelas-kelas tersebut dengan tepat. GET dapat memetakan ke banyak titik akhir yang berbeda, begitu juga yang lain. Sebenarnya tidak ada alasan Anda tidak dapat mengimplementasikan REST-ful JSON-RPC melalui HTTP.
spinkus

5
Ada alasan yang sangat bagus. Saya mungkin ingin beberapa lusin tindakan, dan sudah mengalami penggunaan umum (Android) yang bahkan tidak mendukung PATCH. Itu membunuhnya dingin. Saya lebih suka konsisten daripada harus berurusan dengan beberapa pengecualian terhadap aturan. Secara umum, sekarang saya hanya akan menggunakan GET, POST dan DELETE. PUT tidak mengizinkan umpan balik yang saya inginkan pada operasi pembaruan. Saya menggunakan POST untuk hampir semuanya. Mengenai caching, itu telah menyebabkan banyak masalah dengan mengembalikan data lama. Mengenai menempatkan parameter dalam POST, ASP.NET sudah menanganinya secara otomatis dari objek JSON otomatis.
Bruce Patin

22
Saya percaya pertengkaran tentang apa yang sebenarnya REST hanya menggarisbawahi komentar Anda dan menyoroti kelemahan utama REST. Secara konsep, sulit menemukan dua orang yang sepenuhnya setuju tentang apa itu RESTful. Lagi pula itu tidak masalah karena tidak ada layanan yang harus RPC atau REST tidak berdokumen. Jika didokumentasikan maka pengembang yang menggunakannya seharusnya tidak memiliki masalah.
Agile Jedi

29

Pertama, HTTP-REST adalah arsitektur "representational state transfer". Ini menyiratkan banyak hal menarik:

  • API Anda tidak memiliki kewarganegaraan dan karenanya lebih mudah untuk dirancang (sangat mudah untuk melupakan transisi dalam otomat kompleks), dan untuk berintegrasi dengan bagian-bagian perangkat lunak independen.
  • Anda akan diarahkan untuk merancang metode baca sebagai aman , yang akan mudah di-cache, dan diintegrasikan.
  • Anda akan diarahkan untuk merancang metode penulisan sebagai metode idempoten , yang akan menangani timeout jauh lebih baik.

Kedua, HTTP-REST sepenuhnya sesuai dengan HTTP (lihat "aman" dan "idempoten" di bagian sebelumnya), oleh karena itu Anda akan dapat menggunakan kembali perpustakaan HTTP (ada untuk setiap bahasa yang ada) dan HTTP reverse proxy, yang akan memberi Anda kemampuan untuk mengimplementasikan fitur-fitur canggih (cache, otentikasi, kompresi, redirection, penulisan ulang, logging, dll.) dengan nol baris kode.

Last but not least, menggunakan HTTP sebagai protokol RPC adalah kesalahan besar menurut perancang HTTP 1.1 (dan penemu REST): http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation. htm # sec_6_5_2


1
+1 untuk referensi otoritatif, guy-who-should-know .... Sulit untuk memperdebatkan RPC melalui HTTP setelah itu, tanpa mengakuinya sebagai peretasan /
penyelesaian

9
Anda baru saja mereferensikan sesuatu dari tahun 2000. Ini lebih merupakan argumen filosofis untuk REST versus RPC. Secara semantik dan menerapkan pola RPC Anda dapat dengan mudah menganggap URI sebagai "prosedur" dan parameter yang dikodekan menjadi ... well ... parameter. Salah satu pola akan bekerja dengan baik melalui HTTP. Sama dengan SOAP, RAILS atau sejumlah pola / protokol lain yang telah di overlay ke HTTP. Tidak masalah asalkan Anda menawarkan API yang konsisten dan tidak melanggar kontraknya.
Agile Jedi

Aurélien, dapatkah Anda membenarkan, mengapa REST lebih mudah diintegrasikan dengan komponen perangkat lunak independen? Bagi saya, terlepas dari apakah Anda menggunakan RESTful API atau RPC, perangkat lunak klien perlu mengetahui format pembicaraan API Anda.
Alexey

1
@ Alexey Argumen ini relatif terhadap kewarganegaraan. Hal ini lebih mudah untuk mengintegrasikan mesin kopi yang API adalah CREATE CUP, daripada yang lain yang akan berisi INSERT COIN, SELECT COFFEE, SELECT SUGAR, dan START. Di API kedua, karena tergantung pada status mesin, Anda harus sangat berhati-hati dengan urutan panggilan prosedur.
Aurélien

1
HTTP sebagai protokol RPC adalah REST. Jadi penafsiran Anda yang salah ternyata sangat mengejutkan.
Tiberiu-Ionuț Stan

24

Jawaban yang bagus - hanya ingin menjelaskan beberapa komentar. JSON-RPC cepat dan mudah dikonsumsi, tetapi seperti yang disebutkan sumber daya dan parameternya sangat erat dan cenderung bergantung pada kata kerja (api / deleteUser, api / addUser) menggunakan GET / POST di mana REST menyediakan sumber daya yang digabungkan secara longgar (api / pengguna) yang dalam API HTTP REST bergantung pada beberapa metode HTTP (GET, POST, PUT, PATCH, DELETE). REST sedikit lebih sulit untuk diterapkan oleh pengembang yang tidak berpengalaman, tetapi gaya ini telah menjadi tempat yang cukup umum sekarang dan memberikan fleksibilitas yang lebih besar dalam jangka panjang (memberi API Anda umur yang lebih panjang).

Seiring dengan tidak memiliki sumber daya yang digabungkan secara ketat, REST juga memungkinkan Anda untuk menghindari komitmen pada tipe konten tunggal - ini berarti jika klien Anda perlu menerima data dalam XML, atau JSON, atau bahkan YAML - jika dibangun ke dalam sistem Anda, Anda dapat kembalikan salah satu dari mereka yang menggunakan header tipe-konten / terima.

Ini memungkinkan Anda menjaga API Anda cukup fleksibel untuk mendukung tipe konten baru atau persyaratan klien.

Tetapi apa yang benar-benar memisahkan REST dari JSON-RPC adalah bahwa ia mengikuti serangkaian kendala yang dipikirkan dengan cermat - memastikan fleksibilitas arsitektur. Kendala ini termasuk memastikan bahwa klien dan server dapat berevolusi secara independen satu sama lain (Anda dapat membuat perubahan tanpa mengacaukan aplikasi klien Anda), panggilan stateless (negara diwakili melalui hypermedia), antarmuka yang seragam disediakan untuk interaksi, API dikembangkan pada sistem berlapis, dan responsnya dapat di-cache oleh klien. Ada juga batasan opsional untuk menyediakan kode sesuai permintaan.

Namun, dengan semua ini dikatakan - PALING API tidak Tenang (menurut Fielding) karena mereka tidak memasukkan hypermedia (tautan hiperteks yang disematkan dalam respons yang membantu menavigasi API). Sebagian besar API yang Anda temukan ada seperti REST karena mengikuti sebagian besar konsep REST, tetapi abaikan kendala ini. Namun, semakin banyak API yang menerapkan ini dan itu menjadi lebih dari praktik arus utama.

Ini juga memberi Anda beberapa fleksibilitas karena API yang digerakkan oleh hypermedia (seperti Stormpath) mengarahkan klien ke URI (artinya jika ada perubahan, dalam kasus tertentu Anda dapat memodifikasi URI tanpa dampak negatif), sedangkan RPC URI harus statis. Dengan RPC, Anda juga perlu mendokumentasikan berbagai URI yang berbeda ini dan menjelaskan cara kerjanya terkait satu sama lain.

Secara umum, saya akan mengatakan REST adalah cara untuk pergi jika Anda ingin membangun API yang fleksibel dan dapat diperpanjang yang akan berumur panjang. Untuk alasan itu, saya akan mengatakan itu adalah rute untuk menempuh 99% dari waktu.

Semoga beruntung, Mike


3
itu tidak SANGAT sulit, tetapi lebih sulit. Saya sudah mencoba memahaminya selama 4 bulan atau lebih, dan masih belum memiliki pegangan yang baik tentang bagaimana menulis layanan yang tidak beralih ke RPC tanpa kewarganegaraan melalui http menggunakan json, Dan saya masih belum yakin ada perbedaan nyata antara "REST" dan apa yang baru saja saya katakan
Austin_Anderson

19

IMO, titik kuncinya adalah aksi vs orientasi sumber daya. REST berorientasi pada sumber daya dan sangat cocok untuk operasi CRUD dan mengingat semantiknya yang diketahui memberikan kemungkinan yang dapat diprediksi kepada pengguna pertama, tetapi ketika diimplementasikan dari metode atau prosedur memaksa Anda untuk menyediakan terjemahan buatan ke dunia yang berpusat pada sumber daya. Di sisi lain RPC sangat cocok untuk API berorientasi tindakan, tempat Anda mengekspos layanan, bukan rangkaian sumber daya yang dapat membantu CRUD.

Tidak diragukan lagi REST lebih populer, ini pasti menambah beberapa poin jika Anda ingin mengekspos API ke pihak ketiga.

Jika tidak (misalnya dalam hal membuat front-end AJAX di SPA), pilihan saya adalah RPC. Dalam JSON-RPC tertentu, dikombinasikan dengan Skema JSON sebagai bahasa deskripsi, dan diangkut melalui HTTP atau Websockets tergantung pada kasus penggunaan.

JSON-RPC adalah spesifikasi sederhana dan elegan yang mendefinisikan permintaan dan respons muatan JSON untuk digunakan dalam RPC sinkron atau asinkron.

Skema JSON adalah spesifikasi rancangan yang mendefinisikan format berbasis JSON yang bertujuan untuk menggambarkan data JSON. Dengan menjelaskan pesan input dan output layanan Anda menggunakan Skema JSON Anda dapat memiliki kompleksitas sewenang-wenang dalam struktur pesan tanpa mengurangi kegunaan, dan integrasi layanan dapat diotomatisasi.

Pilihan protokol transport (HTTP vs websockets) tergantung pada faktor yang berbeda, menjadi yang paling penting apakah Anda memerlukan fitur HTTP (caching, validasi ulang, keamanan, idempotensi, tipe konten, multipart, ...) atau apakah aplikasi Anda perlu bertukar pesan pada frekuensi tinggi.

Sampai sekarang ini sangat banyak pendapat pribadi saya tentang masalah ini, tetapi sekarang sesuatu yang bisa sangat membantu bagi para pengembang Java yang membaca baris-baris ini, kerangka kerja yang telah saya kerjakan selama tahun lalu, lahir dari pertanyaan yang sama yang Anda tanyakan sekarang :

http://rpc.brutusin.org

Anda dapat melihat demo langsung di sini, menampilkan browser repositori bawaan untuk pengujian fungsional (terima kasih JSON Schema) dan serangkaian layanan contoh:

http://demo.rpc.brutusin.org

Semoga ini bisa membantu sobat!

Nacho


Sangat menyenangkan menemukan roh yang baik hati! Saya sedang mengerjakan sesuatu yang serupa di sini: github.com/dnault/therapi-json-rpc
dnault

:) Saya akan memeriksanya
idelvall

1
Setuju dengan ini. REST bekerja dengan baik untuk API CRUD karena Anda memiliki POST / GET / PUT / DELETE [PoGPuD? ;)] pemetaan. Namun, jika API Anda tidak cocok dengan kata kerja tersebut, JSON-RPC mungkin merupakan pilihan yang baik karena kata kerja hanya akan membingungkan masalah. Jadi ya, siapa yang menggunakannya dan mengapa merupakan faktor besar.
Algy Taylor

1
Tepat - REST adalah kerajaan kata benda, JSON-RPC adalah kata kerja.
Rob Grant

16

Jika layanan Anda berfungsi dengan baik hanya dengan model dan pola GET / POST / PUT / DELETE, gunakan REST murni.

Saya setuju bahwa HTTP pada awalnya dirancang untuk aplikasi tanpa negara.

Tetapi untuk aplikasi (web) modern, lebih kompleks (!) Di mana Anda ingin menggunakan Websockets (yang sering menyiratkan keadaan penuh), mengapa tidak menggunakan keduanya? JSON-RPC melalui Websockets sangat ringan sehingga Anda memiliki manfaat berikut:

  • Pembaruan instan pada setiap klien (tentukan panggilan RPC server-ke-klien Anda sendiri untuk memperbarui model)
  • Mudah untuk menambahkan kompleksitas (cobalah membuat klon Etherpad dengan hanya REST)
  • Jika Anda melakukannya dengan benar (tambahkan RPC hanya sebagai tambahan untuk waktu-nyata), sebagian besar masih dapat digunakan dengan hanya REST (kecuali jika fitur utamanya adalah obrolan atau sesuatu)

Karena Anda hanya merancang API sisi server, mulailah dengan mendefinisikan model REST dan kemudian tambahkan dukungan JSON-RPC sesuai kebutuhan, menjaga jumlah panggilan RPC seminimal mungkin.

(dan maaf karena terlalu banyak tanda kurung)


15

Saya telah menjadi penggemar berat REST di masa lalu dan memiliki banyak keunggulan dibandingkan RPC di atas kertas. Anda dapat menyajikan klien dengan Jenis Konten, Caching, penggunaan kembali kode status HTTP yang berbeda, Anda dapat memandu klien melalui API dan Anda dapat menyematkan dokumentasi di API jika tidak sebagian besar menjelaskannya sendiri.

Tetapi pengalaman saya adalah bahwa dalam praktiknya ini tidak bertahan dan sebaliknya Anda melakukan banyak pekerjaan yang tidak perlu untuk memperbaiki semuanya. Juga kode status HTTP sering tidak memetakan ke logika domain Anda dengan tepat dan menggunakannya dalam konteks Anda sering terasa agak dipaksakan. Tetapi hal terburuk tentang REST menurut saya adalah Anda menghabiskan banyak waktu untuk merancang sumber daya Anda dan interaksi yang mereka izinkan. Dan setiap kali Anda melakukan beberapa penambahan besar pada API Anda, harap Anda menemukan solusi yang baik untuk menambahkan fungsionalitas baru dan Anda belum mendesain sendiri.

Ini sering terasa seperti buang-buang waktu bagi saya karena sebagian besar waktu saya sudah memiliki ide yang sangat bagus dan jelas tentang cara memodelkan API sebagai seperangkat panggilan prosedur jarak jauh. Dan jika saya telah melalui semua upaya ini untuk memodelkan masalah saya di dalam kendala REST, masalah selanjutnya adalah bagaimana memanggilnya dari klien? Program kami didasarkan pada prosedur panggilan sehingga membangun perpustakaan klien RPC yang baik itu mudah, membangun perpustakaan klien REST yang baik tidak begitu banyak dan dalam kebanyakan kasus Anda hanya akan memetakan kembali dari REST API Anda di server ke serangkaian prosedur di klien Anda Perpustakaan.

Karena itu, RPC terasa jauh lebih sederhana dan lebih alami bagi saya hari ini. Apa yang benar-benar saya lewatkan adalah kerangka kerja konsisten yang membuatnya mudah untuk menulis layanan RPC yang menggambarkan diri sendiri dan interoperable. Karena itu saya membuat proyek saya sendiri untuk bereksperimen dengan cara-cara baru untuk membuat RPC lebih mudah bagi diri saya dan mungkin orang lain juga merasakan manfaatnya: https://github.com/aheck/reflectrpc


Lihat OpenRPC, itu harus mengatasi kebutuhan Anda untuk "mudah untuk menulis layanan RPC yang menggambarkan diri sendiri dan interoperable"
Belfordz

11

Menurut model kematangan Richardson , pertanyaannya bukanlah REST vs RPC , tetapi berapa banyak REST ?

Dalam pandangan ini, kepatuhan terhadap standar REST dapat diklasifikasikan dalam 4 level.

  • level 0: berpikir dalam hal tindakan dan parameter. Seperti yang dijelaskan dalam artikel ini , ini pada dasarnya setara dengan JSON-RPC (artikel menjelaskannya untuk XML-RPC, tetapi argumen yang sama berlaku untuk keduanya).
  • level 1: berpikir dalam hal sumber daya. Segala sesuatu yang relevan dengan sumber daya milik URL yang sama
  • level 2: gunakan kata kerja HTTP
  • level 3: HATEOAS

Menurut pencipta standar REST, hanya layanan level 3 yang dapat disebut RESTful. Namun, ini adalah metrik kepatuhan , bukan kualitas. Jika Anda hanya ingin memanggil fungsi jarak jauh yang melakukan perhitungan, mungkin tidak masuk akal untuk memiliki tautan hypermedia yang relevan dalam respons, tidak ada diferensiasi perilaku berdasarkan kata kerja HTTP yang digunakan. Jadi, panggilan semacam itu secara inheren cenderung lebih mirip RPC. Namun, tingkat kepatuhan yang lebih rendah tidak selalu berarti status penuh, atau hubungan yang lebih tinggi. Mungkin, alih-alih memikirkan REST vs RPC , Anda harus menggunakan REST sebanyak mungkin, tetapi tidak lebih. Jangan memutar aplikasi Anda hanya agar sesuai dengan standar kepatuhan tenang.


1
+1 untuk level 0, 1, dan 2. Namun saya belum pernah melihat implementasi HATEOS yang sukses, tetapi telah melihat dua upaya yang gagal total.
mjhm

8

Mengapa JSON RPC:

Dalam hal API REST, kita harus mendefinisikan pengontrol untuk setiap fungsi / metode yang mungkin kita butuhkan. Akibatnya jika kita memiliki 10 metode yang kita inginkan dapat diakses oleh klien, kita harus menulis 10 pengendali untuk menghubungkan permintaan klien ke metode tertentu.

Faktor lain adalah, meskipun kami memiliki pengontrol yang berbeda untuk setiap metode / fungsi, klien harus ingat apakah menggunakan POST atau GET. Ini semakin memperumit masalah. Selain itu untuk mengirim data, seseorang harus mengatur tipe konten permintaan jika POST digunakan.

Dalam hal JSON RPC, banyak hal yang disederhanakan karena sebagian besar server JSONRPC beroperasi pada metode HTTP POST dan jenis konten selalu aplikasi / json. Ini menghilangkan beban mengingat untuk menggunakan metode HTTP yang tepat dan pengaturan konten di sisi klien.

Seseorang tidak harus membuat pengontrol terpisah untuk berbagai metode / fungsi yang ingin diekspos server ke klien.

Mengapa REST:

Anda memiliki URL terpisah untuk fungsi berbeda yang ingin diekspos server ke sisi klien. Hasilnya, Anda dapat menyematkan url ini.

Sebagian besar poin ini dapat diperdebatkan dan sepenuhnya tergantung pada kebutuhan seseorang.


3

Saya pikir, seperti biasa, itu tergantung ...

REST memiliki keuntungan besar dari dukungan masyarakat luas dan ini berarti banyak alat dan buku. Jika Anda perlu membuat API yang digunakan oleh sejumlah besar konsumen dari organisasi yang berbeda maka itu adalah cara untuk hanya karena satu alasan: itu populer. Sebagai protokol tentu saja ini merupakan kegagalan total karena ada terlalu banyak cara yang sangat berbeda untuk memetakan perintah ke URL / kata kerja / respons.

Karena itu, ketika Anda menulis aplikasi web satu halaman yang perlu berbicara dengan backend maka saya pikir REST terlalu rumit. Dalam situasi ini Anda tidak perlu khawatir tentang kompatibilitas jangka panjang karena aplikasi dan API dapat berkembang bersama.

Saya pernah memulai dengan REST untuk aplikasi web satu halaman tetapi perintah-perintah berbutir halus antara aplikasi web dan server dengan cepat membuat saya gila. Haruskah saya menyandikannya sebagai parameter jalur? Di dalam tubuh? Parameter kueri? Header? Setelah desain URL / Verb / Response saya kemudian harus kode kekacauan ini di Javascript, decoder di Java dan kemudian memanggil metode yang sebenarnya. Meskipun ada banyak alat untuk itu, sangat sulit untuk tidak mendapatkan semantik HTTP dalam kode domain Anda, yang merupakan praktik yang sangat buruk. (Kohesi)

Coba buat file Swagger / OpenAPI untuk situs kompleks menengah dan bandingkan dengan antarmuka Java tunggal yang menjelaskan prosedur jarak jauh dalam file itu. Peningkatan kompleksitas sangat mengejutkan.

Karena itu saya beralih dari REST ke JSON-RPC untuk satu halaman webapp. aI mengembangkan perpustakaan kecil yang menyandikan antarmuka Java di server dan mengirimkannya ke browser. Di browser ini dibuat proksi untuk kode aplikasi yang mengembalikan janji untuk setiap fungsi.

Sekali lagi, REST memiliki tempatnya hanya karena terkenal dan karenanya didukung dengan baik. Juga penting untuk mengenali filosofi sumber daya tanpa negara yang mendasari dan model hierarkis. Namun, prinsip-prinsip ini dapat dengan mudah digunakan dalam model RPC. JSON RPC berfungsi melalui HTTP sehingga memiliki keunggulan REST yang sama di area ini. Perbedaannya adalah ketika Anda secara tidak terhindarkan mengalami fungsi-fungsi ini yang tidak memetakan dengan baik prinsip-prinsip ini, Anda tidak dipaksa untuk melakukan banyak pekerjaan yang tidak perlu.


1
Jawaban ini membuat saya menyadari kesamaan antara GraphQL dan JSON-RPC dan mengapa GraphQL menjadi pilihan populer untuk SPA.
Dennis

OpenRPC setara dengan OpenAPI / Swagger, tetapi untuk JSON-RPC
Belfordz

1

REST sangat erat dengan HTTP, jadi jika Anda hanya mengekspos API Anda melalui HTTP maka REST lebih tepat untuk sebagian besar (tetapi tidak semua) situasi. Namun, jika Anda perlu mengekspos API Anda di atas transportasi lain seperti pesan atau soket web maka REST tidak berlaku.


2
REST adalah gaya arsitektur dan tidak bergantung pada protokol.
Mark Cidade

4
Anda benar REST adalah prinsip arsitektur. Namun, landasan teoretisnya sangat dipengaruhi oleh protokol HTTP dan meskipun ada klaim penerapan universal, ia tidak menemukan aplikasi praktis di luar domain web. Jadi, aman untuk mengatakan bahwa ketika seseorang menyebutkan REST, mereka merujuk ke layanan web dan bukan prinsip arsitektur.
dtoux

1

Akan lebih baik untuk memilih JSON-RPC antara REST dan JSON-RPC untuk mengembangkan API untuk aplikasi web yang lebih mudah dipahami. JSON-RPC lebih disukai karena pemetaannya untuk panggilan metode dan komunikasi dapat dengan mudah dipahami.

Memilih pendekatan yang paling sesuai tergantung pada kendala atau tujuan utama. Misalnya, sejauh kinerja adalah sifat utama, disarankan untuk menggunakan JSON-RPC (misalnya, Komputasi Kinerja Tinggi). Namun, jika tujuan utamanya adalah menjadi agnostik untuk menawarkan antarmuka generik untuk disimpulkan oleh orang lain, disarankan untuk menggunakan REST. Jika kedua tujuan Anda perlu dicapai, disarankan untuk menyertakan kedua protokol.

Fakta yang benar-benar memisahkan REST dari JSON-RPC adalah bahwa ia menelusuri serangkaian kendala yang dipikirkan dengan cermat - mengkonfirmasikan fleksibilitas arsitektur. Kendala dalam memastikan bahwa klien dan server dapat tumbuh secara independen satu sama lain (perubahan dapat dilakukan tanpa mengacaukan aplikasi klien), panggilan tidak bernegara (negara dianggap sebagai hypermedia), seragam antarmuka ditawarkan untuk interaksi, API dimajukan pada sistem berlapis (Hall, 2010). JSON-RPC cepat dan mudah dikonsumsi, namun seperti sumber daya yang disebutkan serta parameternya digabungkan secara ketat dan cenderung bergantung pada kata kerja (api / addUser, api / deleteUser) menggunakan GET / POST sedangkan REST memberikan sumber daya yang digabungkan secara longgar (api / pengguna) dalam HTTP. REST API bergantung pada beberapa metode HTTP seperti GET, PUT, POST, DELETE, PATCH.

JSON (dilambangkan sebagai JavaScript Object Notation) menjadi format pertukaran data yang ringan, mudah bagi manusia untuk membaca dan menulis. Tidak mudah bagi mesin untuk mengurai dan menghasilkan. JSON adalah format teks yang sepenuhnya bebas bahasa tetapi mempraktikkan konvensi yang dikenali oleh programmer dari keluarga bahasa, yang terdiri dari C #, C, C ++, Java, Perl, JavaScript, Python, dan banyak lainnya. Properti seperti itu menjadikan JSON bahasa pertukaran-data yang sempurna dan pilihan yang lebih baik untuk dipilih.


"Ini tidak merepotkan bagi mesin untuk mengurai" - Saya telah melihat banyak JSON yang rusak (mis. Kutipan yang tidak
terhapuskan

1

Pertanyaan yang salah: memaksakan manichean yang tidak ada!

Anda dapat menggunakan JSON-RPC dengan "less verb" (tanpa metode ) dan mempertahankan standarisasi minimal yang diperlukan untuk sendo id, parameter, kode kesalahan , dan pesan peringatan . Standar JSON-RPC tidak mengatakan "Anda tidak bisa menjadi REST", hanya mengatakan bagaimana mengemas informasi dasar.

"REST JSON-RPC" ada ! adalah REST dengan "praktik terbaik", untuk pengemasan informasi minimal, dengan kontrak sederhana dan solid.


Contoh

(dari jawaban ini dan konteks didaktik)

Ketika berhadapan dengan REST, umumnya membantu memulai dengan berpikir dalam hal sumber daya. Dalam hal ini, sumber daya bukan hanya "rekening bank" tetapi merupakan transaksi dari rekening bank itu ... Tetapi JSON-RPC tidak mewajibkan parameter "metode", semua dikodekan oleh "jalur" dari titik akhir.

  • REST Deposit dengan POST /Bank/Account/John/Transactionpermintaan JSON {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
    Respons JSON dapat berupa sesuatu{"jsonrpc": "2.0", "result": "sucess", "id": 12}

  • SISA Penarikan dengan POST /Bank/Account/John/Transaction... serupa.

  • ... GET /Bank/Account/John/Transaction/12345@13... Ini dapat mengembalikan catatan JSON dari transaksi persis itu (mis. Pengguna Anda umumnya menginginkan catatan debit dan kredit pada akun mereka). Sesuatu seperti {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. Konvensi tentang (REST) ​​permintaan GET dapat menyertakan penyandian id oleh "@id", jadi tidak perlu mengirim JSON apa pun, tetapi masih menggunakan JSON-RPC dalam paket respons.



0

Jika Anda meminta sumber daya, maka RESTful API menurut desain lebih baik. Jika Anda meminta beberapa data rumit dengan banyak parameter dan metode rumit selain CRUD sederhana, maka RPC adalah cara yang tepat.


Ini adalah terlalu banyak penyederhanaan topik. Mengapa, secara khusus, apakah "Lebih baik dengan desain"? JSON-RPC dapat sesederhana atau serumit yang Anda inginkan, dan argumennya adalah "lebih baik 'untuk" banyak parameter dan metode rumit "juga salah. Tidak ada yang lebih baik atau lebih buruk dalam hal ini
Belfordz

Tidak masalah jika RPC menggunakan JSON atau protobuf atau XML untuk membuat serial data. Poin kuncinya adalah API seperti yang saya katakan. Maksudku bukan yang satu lebih baik dari yang lain dalam semua kasus. Tapi saya pikir parameter dan metode penting ketika Anda memilih antara dua implementasi. Jika sederhana, RESTful API dipahami dengan baik oleh sebagian besar programmer dan Anda dapat dengan mudah membuat permintaan http. Jika rumit, RPC lebih mampu mengekspresikan API semacam itu, dan IDE dan kompiler Anda dapat membantu Anda.
Adrian Liu

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.