REST vs JSON-RPC? [kapalı]

Bir web uygulaması için bir API geliştirmek için REST ve JSON-RPC arasında seçim yapmaya çalışıyorum. Nasıl karşılaştırırlar?

2015 Güncellemesi: Web / HTTP'de sunulan bir API için REST'in geliştirilmesini ve kullanılmasını daha kolay buldum, çünkü hem istemci hem de sunucu tarafından anlaşılan mevcut ve olgun HTTP protokolü API tarafından kullanılabilir. Örneğin, yanıt kodları, başlıklar, sorgular, posta gövdeleri, önbellekleme ve diğer birçok özellik API tarafından herhangi bir ek çaba veya kurulum yapılmadan kullanılabilir.

RPC ile ilgili temel sorun bağlantıdır. RPC istemcileri çeşitli şekillerde hizmet uygulamasına sıkı sıkıya bağlı hale gelir ve istemcileri bozmadan hizmet uygulamasını değiştirmek çok zorlaşır:

• Müşterilerin prosedür adlarını bilmesi gerekir;
• Prosedür parametreleri sırası, türleri ve sayım konuları. İstemci uygulamalarını bozmadan sunucu tarafındaki yordam imzalarını (bağımsız değişken sayısı, bağımsız değişken sırası, bağımsız değişken türleri vb.) Değiştirmek o kadar kolay değildir;
• RPC stili yordam uç noktaları + yordam bağımsız değişkenlerinden başka bir şey göstermez. Müşterinin bundan sonra ne yapabileceğini belirlemesi imkansız.

Öte yandan REST stilinde, kontrol bilgilerini temsillere (HTTP üstbilgileri + temsil) ekleyerek istemcilere rehberlik etmek çok kolaydır. Örneğin:

• Bu URI'lerin anlamlarını ileten bağlantı ilişkisi türlerine açıklamalı bağlantılar gömmek mümkündür (ve aslında zorunludur);
• İstemci uygulamalarının belirli yordam adlarına ve bağımsız değişkenlerine bağlı olması gerekmez. Bunun yerine, istemciler ileti biçimlerine bağlıdır. Bu, belirli ortam formatları için halihazırda uygulanmış kütüphaneleri kullanma imkanı yaratır (örn. Atom, HTML, Collection + JSON, HAL vb.)
• URI'leri, istemcileri yalnızca kayıtlı (veya etki alanına özgü) bağlantı ilişkilerine bağlı oldukları sürece bozmadan kolayca değiştirmek mümkündür;
• Form benzeri yapıları temsillere gömmek, istemcilere son kullanıcı insansa bu açıklamaları UI yetenekleri olarak gösterme imkanı vermek mümkündür;
• Önbellek desteği ek avantajdır;
• Standart durum kodları;

REST tarafında çok daha fazla fark ve avantaj var.

Sorunu biraz ayrıntılı bir şekilde inceledim ve uygulamaların çoğunun CRUD uygulamaları olmasına rağmen saf REST'in çok sınırlayıcı olduğuna ve RPC'nin en iyisi olduğuna karar verdim. REST'e sadık kalırsanız, sonunda kafanızı kaşıracaksınız, özel bir amaç için API'nize gerekli başka bir yöntemi nasıl kolayca ekleyebileceğinizi merak edeceksiniz. Çoğu durumda, bunu REST ile yapmanın tek yolu, programınızı gereksiz yere zorlaştırabilecek başka bir denetleyici oluşturmaktır.

RPC'ye karar verirseniz, tek fark, fiili açıkça, URI'nin bir parçası olarak belirtmenizdir; bu, net, tutarlı, daha az buggy ve gerçekten sorun değildir. Özellikle basit CRUD'un ötesine geçen bir uygulama oluşturursanız, RPC tek yoludur. RESTful purists ile başka bir sorun var: HTTP POST, GET, PUT, DELETE HTTP'de REST tarafından başka şeylere dönüştürülmüş kesin anlamlara sahiptir, çünkü çoğu zaman uyuyorlar - ama her zaman değil.

Programlamada, uzun zaman önce, bir şeyi iki şey ifade etmek için kullanmaya çalışmanın bir süre gelip sizi ısırdığını buldum. POST'u hemen hemen her eylem için kullanma yeteneğine sahip olmayı seviyorum, çünkü yönteminizin yapması gerektiği gibi veri gönderme ve alma özgürlüğü sağlar. Tüm dünyayı CRUD'a sığdıramazsınız.

İlk olarak, HTTP-REST bir "temsili durum aktarımı" mimarisidir. Bu birçok ilginç şey anlamına gelir:

• API'nız durumsuz olacak ve bu nedenle tasarımı çok daha kolay olacak (karmaşık bir otomattaki bir geçişi unutmak gerçekten kolay) ve bağımsız yazılım parçalarıyla entegrasyon.
• Önbelleğe alınması ve entegre edilmesi kolay olacak şekilde güvenli okuma yöntemleri olarak tasarım yöntemlerine yönlendirileceksiniz .
• Tasarım yazma yöntemlerine zaman aşımı ile çok daha iyi başa çıkacak olan idempotent yöntemler olarak yönlendirileceksiniz .

İkincisi, HTTP-REST HTTP ile tamamen uyumludur (önceki bölümde "güvenli" ve "idempotent" e bakın), bu nedenle HTTP kütüphanelerini (mevcut her dil için mevcut) ve HTTP ters proxy'lerini yeniden kullanabileceksiniz. sıfır kod satırı ile gelişmiş özellikleri (önbellek, kimlik doğrulama, sıkıştırma, yeniden yönlendirme, yeniden yazma, günlük tutma, vb.) uygulama yeteneği.

Son fakat en az değil, HTTP'yi RPC protokolü olarak kullanmak, HTTP 1.1 (ve REST'in mucidi) tasarımcısına göre büyük bir hatadır: http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation. htm # sec_6_5_2

Harika cevaplar - sadece bazı yorumlara açıklık getirmek istedim. JSON-RPC'nin kullanımı hızlı ve kolaydır, ancak bahsedilen kaynaklar ve parametreler sıkıca bağlanır ve REST gevşek bağlanmış kaynaklar (api / HTTP REST API'sindeki çeşitli HTTP yöntemlerine (GET, POST, PUT, PATCH, DELETE) dayanmaktadır. REST, deneyimsiz geliştiricilerin uygulaması için biraz daha zordur, ancak stil şimdi oldukça yaygın bir yer haline gelmiştir ve uzun vadede çok daha fazla esneklik sağlar (API'nize daha uzun bir ömür sağlar).

Sıkı birleştirilmiş kaynaklara sahip olmamanın yanı sıra, REST ayrıca tek bir içerik türüne bağlı kalmaktan kaçınmanıza izin verir - bu, müşterinizin verileri XML, JSON veya hatta YAML'de alması gerekiyorsa - sisteminizde yerleşikse content-type / accept başlıklarını kullananlardan herhangi birini döndürür.

Bu, API'nızı yeni içerik türlerini VEYA istemci gereksinimlerini destekleyecek kadar esnek tutmanıza olanak tanır.

Ancak REST'i JSON-RPC'den gerçekten ayıran şey, mimari esnekliği garanti eden bir dizi dikkatle düşünülmüş kısıtlamayı takip etmesidir. Bu kısıtlamalar arasında, istemci ve sunucunun birbirinden bağımsız olarak evrimleşebilmesini sağlamak (müşterinizin uygulamasını bozmadan değişiklikler yapabilirsiniz), çağrılar vatansızdır (durum hipermedya ile temsil edilir), etkileşimler için tek tip bir arayüz sağlanır, API katmanlı bir sistemde geliştirilmiştir ve yanıt istemci tarafından önbelleğe alınabilir. İsteğe bağlı kod sağlama konusunda isteğe bağlı bir kısıtlama da vardır.

Bununla birlikte, tüm bunlar ile - MOST API'leri, hiper ortam (API'da gezinmeye yardımcı olan yanıtta gömülü hipermetin bağlantıları) içermediğinden RESTful (Fielding'e göre) değildir. Bulabileceğiniz çoğu API, REST kavramlarının çoğunu takip etmeleri, ancak bu kısıtlamayı görmezden gelmeleri nedeniyle REST benzeri olduğunu göreceksiniz. Bununla birlikte, giderek daha fazla API bunu uygulamaktadır ve giderek daha fazla ana akış uygulaması haline gelmektedir.

Bu aynı zamanda, hiper ortam tarafından yönlendirilen API'ler (Stormpath gibi) istemciyi URI'lara yönlendirdiği için esneklik sağlar (yani, bir şey değişirse, bazı durumlarda URI'yi olumsuz etki olmadan değiştirebilirsiniz), burada RPC URI'larında olduğu gibi statik. RPC ile, bu farklı URI'ları kapsamlı bir şekilde belgelemeniz ve birbirleriyle ilişkili olarak nasıl çalıştıklarını açıklamanız gerekecektir.

Genel olarak, uzun ömürlü olacak, genişletilebilir, esnek bir API oluşturmak istiyorsanız REST'in gitmenin yolu olduğunu söyleyebilirim. Bu nedenle, zamanın% 99'una giden yol olduğunu söyleyebilirim.

İyi şanslar, Mike

IMO, kilit nokta, eylemin kaynak yönüne karşı olmasıdır. REST, kaynak odaklıdır ve CRUD işlemleri için çok uygundur ve bilinen semantiği ilk kullanıcıya biraz öngörülebilirlik sağlar, ancak yöntemlerden veya prosedürlerden uygulandığında sizi kaynak merkezli dünyaya yapay bir çeviri sağlamaya zorlar. Öte yandan RPC, CRUD özellikli kaynak kümelerine değil, hizmetleri ortaya koyduğunuz eyleme yönelik API'lere mükemmel uyum sağlar.

Şüphesiz REST daha popülerdir, API'yı üçüncü bir tarafa göstermek istiyorsanız bu kesinlikle bazı puanlar ekler.

Değilse (örneğin bir SPA'da AJAX ön ucu oluşturma durumunda), seçimim RPC'dir. Özellikle JSON-RPC, açıklama dili olarak JSON Şeması ile birlikte kullanılır ve kullanım durumuna bağlı olarak HTTP veya Web Soketleri üzerinden taşınır.

JSON-RPC , senkron veya asenkron RPC'de kullanılacak istek ve yanıt JSON yüklerini tanımlayan basit ve zarif bir özelliktir.

JSON Şeması , JSON verilerini tanımlamayı amaçlayan JSON tabanlı bir biçimi tanımlayan taslak özelliktir. JSON Şeması kullanarak hizmet giriş ve çıkış iletilerinizi açıklayarak, kullanılabilirlikten ödün vermeden ileti yapısında rasgele bir karmaşıklığa sahip olabilirsiniz ve hizmet tümleştirmesi otomatikleştirilebilir.

Aktarım protokolünün seçimi (HTTP ve websockets), HTTP özelliklerine (önbellek, yeniden doğrulama, güvenlik, idempotence, içerik türü, çok parçalı, ...) ihtiyacınız olup olmadığı veya uygulamanın takas etmesi gerekip gerekmediği en önemli faktördür. yüksek frekansta mesajlar.

Şimdiye kadar bu konu hakkındaki kişisel fikrim çok, ama şimdi bu satırları okuyan Java geliştiricileri için gerçekten yararlı olabilecek bir şey, son yıl boyunca üzerinde çalıştığım çerçeve, şu anda merak ettiğiniz aynı sorudan doğdu :

http://rpc.brutusin.org

Burada, işlevsel testler için yerleşik depo tarayıcısını (teşekkürler JSON Schema) ve bir dizi örnek hizmeti gösteren canlı bir demo görebilirsiniz:

http://demo.rpc.brutusin.org

Umarım dostum olur!

Nacho

Hizmetiniz yalnızca modellerde ve GET / POST / PUT / DELETE deseniyle iyi çalışıyorsa, saf REST kullanın.

HTTP'nin başlangıçta vatansız uygulamalar için tasarlandığını kabul ediyorum.

Ancak, Websockets'i kullanmak isteyeceğiniz modern, daha karmaşık (!) Gerçek zamanlı (web) uygulamalar için (genellikle durum bilgisi anlamına gelir), neden her ikisini de kullanmıyorsunuz? Websockets üzerinden JSON-RPC çok hafif olduğundan aşağıdaki avantajlara sahipsiniz:

• Her istemcide anında güncelleme (modelleri güncellemek için kendi sunucudan istemciye RPC çağrınızı tanımlayın)
• Karmaşıklık eklemek kolaydır (yalnızca REST ile bir Etherpad klonu yapmaya çalışın)
• Doğru yaparsanız (RPC'yi yalnızca gerçek zamanlı olarak ekstra olarak ekleyin), çoğu yalnızca REST ile kullanılabilir (ana özellik bir sohbet veya başka bir şey hariç)

Yalnızca sunucu tarafı API'sını tasarlarken, REST modellerini tanımlamakla başlayın ve daha sonra gerektiği gibi JSON-RPC desteğini ekleyerek RPC çağrılarının sayısını minimumda tutun.

(ve parantezlerin aşırı kullanımı için üzgünüm)

Geçmişte REST'in büyük bir hayranıydım ve kağıt üzerinde RPC'ye göre birçok avantajı var. İstemciye farklı İçerik Türleri, Önbellekleme, HTTP durum kodlarının yeniden kullanımı sunabilir, istemciyi API aracılığıyla yönlendirebilir ve çoğunlukla kendi kendini açıklamıyorsa belgeleri API'ya gömebilirsiniz.

Ancak benim deneyimim, pratikte bunun dayanmadığı ve bunun yerine her şeyi doğru yapmak için çok fazla gereksiz iş yaptığınız oldu. Ayrıca HTTP durum kodları genellikle alan mantığınızla tam olarak eşleşmez ve bunları bağlamınızda kullanmak biraz zorlanır. Ancak REST ile ilgili en kötü şey, kaynaklarınızı ve izin verdikleri etkileşimleri tasarlamak için çok zaman harcamanız. API'nıza bazı önemli eklemeler yaptığınızda, yeni işlevselliği eklemek için iyi bir çözüm bulduğunuzu ve kendinizi zaten bir köşeye tasarlamadığınızı umarsınız.

Bu çoğu zaman benim için zaman kaybı gibi geliyor çünkü çoğu zaman bir API'yi bir dizi uzaktan prosedür çağrısı olarak nasıl modelleyeceğime dair gayet iyi ve açık bir fikrim var. Ve eğer REST kısıtlamaları içinde sorunumu modellemek için tüm bu çabalardan geçtiysem, bir sonraki sorun onu istemciden nasıl arayacaksınız? Programlarımız çağıran prosedürlere dayanmaktadır, bu nedenle iyi bir RPC istemci kütüphanesi oluşturmak kolaydır, iyi bir REST istemci kütüphanesi oluşturmak çok fazla değildir ve çoğu durumda sunucudaki REST API'nizden istemcinizdeki bir dizi prosedüre geri dönersiniz. kütüphane.

Bu nedenle, RPC bugün bana çok daha basit ve daha doğal geliyor. Gerçekten özlediğim şey, kendini tanımlayan ve birlikte çalışabilir RPC hizmetleri yazmayı kolaylaştıran tutarlı bir çerçevedir. Bu nedenle, RPC'yi kendim için daha kolay hale getirmenin yeni yollarını denemek için kendi projemi oluşturdum ve belki de başka biri de yararlı buldu: https://github.com/aheck/reflectrpc

Göre Richardson olgunluk modeli , soru değil DİNLENME vs RPC , ama ne kadar DİNLENME ?

Bu görüşe göre, REST standardına uyum 4 düzeyde sınıflandırılabilir.

• seviye 0: eylemler ve parametreler açısından düşünün. Makalenin açıkladığı gibi, bu temelde JSON-RPC'ye eşdeğerdir (makale XML-RPC için açıklar, ancak her ikisi için de aynı argümanlar geçerlidir).
• seviye 1: kaynaklar açısından düşünün. Bir kaynakla alakalı her şey aynı URL'ye aittir
• seviye 2: HTTP fiillerini kullanın
• seviye 3: HATEOAS

REST standardının yaratıcısına göre, sadece 3. seviye hizmetler RESTful olarak adlandırılabilir. Ancak, bu kalite değil bir uyum metriğidir . Yalnızca hesaplama yapan bir uzak işlevi çağırmak istiyorsanız, yanıtta ilgili hiper ortam bağlantılarına sahip olmanın hiçbir anlamı yoktur, ne de kullanılan HTTP fiiline göre davranış farklılaşması. Yani, böyle bir çağrı doğal olarak daha fazla RPC benzeri olma eğilimindedir. Bununla birlikte, daha düşük uyumluluk düzeyi durumsallık veya daha yüksek eşleşme anlamına gelmez. Muhtemelen, REST ve RPC'yi düşünmek yerine, mümkün olduğunca fazla REST kullanmalısınız, ancak daha fazla kullanmamalısınız. Uygulamanızı sadece RESTful uyumluluk standartlarına uyacak şekilde bükmeyin.

Neden JSON RPC:

REST API'lerinde, ihtiyaç duyabileceğimiz her işlevsellik / yöntem için bir denetleyici tanımlamamız gerekir. Sonuç olarak, bir istemcinin erişmesini istediğimiz 10 yöntemimiz varsa, istemcinin isteğini belirli bir yönteme arayüzlemek için 10 denetleyici yazmamız gerekir.

Diğer bir faktör, her yöntem / işlevsellik için farklı denetleyicilerimiz olmasına rağmen, istemcinin POST veya GET kullanıp kullanmayacağını hatırlaması gerekir. Bu işleri daha da karmaşık hale getirir. Üstelik veri göndermek için POST kullanılıyorsa, talebin içerik türünü ayarlamak gerekir.

JSON RPC durumunda, çoğu JSONRPC sunucusu POST HTTP yöntemlerinde çalıştığı ve içerik türü her zaman application / json olduğu için işler büyük ölçüde basitleştirilmiştir. Bu, istemci tarafında uygun HTTP yöntemini ve içerik ayarlarını kullanmayı hatırlamanın yükünü ortadan kaldırır.

Sunucunun bir istemciye göstermek istediği farklı yöntemler / işlevler için ayrı denetleyiciler oluşturmak gerekmez.

Neden REST:

Sunucunun istemci tarafına göstermek istediği farklı işlevler için ayrı URL'leriniz var. Sonuç olarak, bu URL'leri gömebilirsiniz.

Bu noktaların çoğu tartışmalıdır ve tamamen bir kişinin ihtiyacına bağlıdır.

Bence, her zamanki gibi, bu ...

REST, yaygın kamu desteğinin büyük avantajına sahiptir ve bu da birçok araç ve kitap anlamına gelir. Farklı kuruluşlardan çok sayıda tüketici tarafından kullanılan bir API yapmanız gerekiyorsa, bu sadece bir nedenden ötürü gitmenin yoludur: popülerdir. Protokol olarak, bir komutu bir URL / fiil / yanıta eşlemek için tamamen farklı birçok yol olduğundan elbette toplam bir hatadır.

Bu nedenle, bir arka uçla konuşması gereken tek bir web uygulaması yazdığınızda REST'in çok karmaşık olduğunu düşünüyorum. Bu durumda, uygulama ve API birlikte gelişebileceğinden uzun vadeli uyumluluk konusunda endişelenmenize gerek yoktur.

Bir keresinde tek sayfalık bir web uygulaması için REST ile başladım, ancak web uygulaması ve sunucu arasındaki ince taneli komutlar beni çabucak çıldırdı. Bunu bir yol parametresi olarak kodlamalı mıyım? Vücutta? Bir sorgu parametresi mi? Bir başlık mı? URL / Fiil / Yanıt tasarımından sonra bu karışıklığı Javascript, Java kod çözücü kodlamak ve sonra gerçek yöntemi çağırmak zorunda kaldı. Bunun için birçok araç olmasına rağmen, alan kodunuzda herhangi bir HTTP anlambilimi almamak gerçekten zor, bu da gerçekten kötü bir uygulamadır. (Uyum)

Orta karmaşık bir site için bir Swagger / OpenAPI dosyası oluşturmayı deneyin ve bu dosyayı o dosyadaki uzak yordamları açıklayan tek bir Java arabirimiyle karşılaştırın. Karmaşıklık artışı şaşırtıcı.

Bu nedenle tek sayfalık web uygulaması için REST'ten JSON-RPC'ye geçtim. Sunucudaki Java arayüzünü kodlayan ve tarayıcıya gönderen küçük bir kütüphane geliştirdim. Tarayıcıda bu, her kod için bir söz veren uygulama kodu için bir proxy oluşturdu.

Yine REST, ünlü olması ve bu nedenle iyi desteklenmesi nedeniyle yerini almıştır. Temeldeki vatansız kaynaklar felsefesini ve hiyerarşik modeli tanımak da önemlidir. Bununla birlikte, bu prensipler bir RPC modelinde de kolaylıkla kullanılabilir. JSON RPC HTTP üzerinden çalışır, bu nedenle bu alanda REST ile aynı avantajlara sahiptir. Aradaki fark, kaçınılmaz olarak, bu ilkelere iyi uymayan bu işlevlerle karşılaştığınızda, çok fazla gereksiz iş yapmak zorunda kalmamanızdır.

REST, HTTP ile sıkı sıkıya bağlıdır, bu nedenle API'nizi yalnızca HTTP üzerinden ortaya çıkarırsanız, REST çoğu (ancak tümü değil) durum için daha uygundur. Bununla birlikte, API'nizi mesajlaşma veya web soketleri gibi diğer aktarımlara maruz bırakmanız gerekiyorsa, REST geçerli değildir.

Anlaması daha kolay bir web uygulaması için API geliştirmek üzere REST ile JSON-RPC arasında JSON-RPC seçmek daha iyi olur. JSON-RPC tercih edilir, çünkü yöntem çağrıları ve iletişim ile eşleşmesi kolayca anlaşılabilir.

En uygun yaklaşımı seçmek kısıtlamalara veya temel amaca bağlıdır. Örneğin, performans önemli bir özellik olduğu sürece, JSON-RPC'yi (örneğin, Yüksek Performanslı Bilgi İşlem) tercih etmeniz önerilir. Bununla birlikte, asıl amaç başkaları tarafından çıkarılacak genel bir arayüz sunmak için agnostik olmaksa, REST'e gitmeniz tavsiye edilir. Her iki hedefinize de ulaşmanız gerekiyorsa, her iki protokolü de dahil etmeniz önerilir.

REST'i JSON-RPC'den ayıran gerçek şu ki, mimari esnekliği onaylayan bir dizi dikkatle düşünülmüş kısıtlamayı takip ediyor. Kısıtlamalar, istemcinin ve sunucunun birbirinden bağımsız olarak büyüyebilmesini (istemcinin uygulamasına zarar vermeden değişiklikler yapılabilmesini) sağlar, çağrılar vatansızdır (durum hiper ortam olarak kabul edilir), üniforma arayüz etkileşimler için sunulur, API katmanlı bir sistemde ilerletilir (Hall, 2010). JSON-RPC'nin hızlı ve kullanımı kolaydır, ancak bahsedilen kaynakların yanı sıra parametreler sıkıca bağlanır ve GET / POST kullanan fiillere (api / addUser, api / deleteUser) bağlı olması muhtemeldir, oysa REST gevşek bağlı kaynaklar (api) sağlar / users) olarak adlandırılır. REST API, GET, PUT, POST, DELETE, PATCH gibi çeşitli HTTP yöntemlerine bağlıdır.

Hafif bir veri alışverişi biçimi olan JSON (JavaScript Nesne Gösterimi olarak ifade edilir), insanların okuması ve yazması kolaydır. Makinelerin ayrıştırılması ve üretilmesi zahmetsizdir. JSON tamamen dilden bağımsız bir metin biçimidir ancak C #, C, C ++, Java, Perl, JavaScript, Python ve diğer pek çok dilden oluşan dil ailesinin programcılarına tanıyan kurallar uygular. Bu tür özellikler JSON'u mükemmel bir veri değişim dili ve tercih etmek için daha iyi bir seçim yapar.

Yanlış soru: var olmayan bir manichene empoze eder!

JSON-RPC'yi "daha az fiil" ( yöntem yok ) ile kullanabilir ve sendo id, parametreler, hata kodları ve uyarı mesajları için gereken minimum standardizasyonu koruyabilirsiniz . JSON-RPC standardı "REST olamazsınız" demez, sadece temel bilgileri nasıl paketleyeceğinizi söyler.

"REST JSON-RPC" mevcut ! basit ve sağlam sözleşmelerle minimum bilgi paketleme için "en iyi uygulamalar" ile REST'tir.

Misal

( bu cevaptan ve didaktik bağlamdan)

REST ile uğraşırken, genellikle kaynaklar açısından düşünerek başlamaya yardımcı olur. Bu durumda, kaynak sadece "banka hesabı" değil, o banka hesabının bir işlemidir ... Ancak JSON-RPC "method" parametresini zorunlu kılmaz, hepsi uç noktanın "path" yolu ile kodlanır.

• DİNLENME Mevduat ile POST /Bank/Account/John/TransactionJSON isteği ile {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
  JSON yanıtı şu şekilde olabilir:{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• DİNLENME geri çek ile POST /Bank/Account/John/Transaction... benzer.

• ... GET /Bank/Account/John/Transaction/12345@13... Bu, söz konusu işlemin JSON kaydını döndürebilir (örneğin, kullanıcılarınız genellikle hesaplarındaki borç ve alacakların kaydını isterler). Gibi bir şey {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. (REST) ​​GET isteği ile ilgili kural, "@id" ile id kodlamasını içerebilir, bu nedenle herhangi bir JSON göndermenize gerek yoktur, ancak yine de yanıt paketinde JSON-RPC kullanılır.

Kaynak talep ederseniz, RESTful API tasarım açısından daha iyidir. Basit CRUD dışında çok sayıda parametreye ve karmaşık yöntemlere sahip bazı karmaşık veriler talep ediyorsanız, RPC gitmek için doğru yoldur.

RPC protokolü için vdata kullanıyorum: http://vdata.dekuan.org/

1, PHP ve JavaScript her ikisi de iyidir. 2, Kaynaklar arası kaynak paylaşımı (CORS) çağrısı hala iyidir.