REST vs JSON-RPC? [Tutup]

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.

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.

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.

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

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

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

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)

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

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.

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.

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.

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.

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.

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.

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.

Saya menggunakan vdata untuk protokol RPC: http://vdata.dekuan.org/

1, PHP dan JavaScript sama-sama oke. 2, panggilan cross-origin resource sharing (CORS) masih baik-baik saja.