REST vs JSON-RPC? [Zamknięte]

Próbuję wybrać między REST i JSON-RPC do opracowania interfejsu API dla aplikacji sieci web. Jak oni się porównują?

Aktualizacja 2015: Odkryłem, że REST jest łatwiejszy do opracowania i używania dla interfejsu API, który jest obsługiwany w sieci Web / HTTP, ponieważ istniejący i dojrzały protokół HTTP, który jest rozumiany zarówno przez klienta, jak i serwer, może być wykorzystywany przez API. Na przykład kody odpowiedzi, nagłówki, zapytania, treści postów, pamięć podręczna i wiele innych funkcji mogą być używane przez interfejs API bez dodatkowego wysiłku lub konfiguracji.

Podstawowym problemem związanym z RPC jest sprzężenie. Klienci RPC są ściśle powiązani z implementacją usług na kilka sposobów i bardzo trudno jest zmienić implementację usługi bez rozbijania klientów:

• Klienci muszą znać nazwy procedur;
• Kolejność parametrów procedury, typy i liczba mają znaczenie. Zmiana podpisów procedur (liczba argumentów, kolejność argumentów, typy argumentów itp.) Po stronie serwera nie jest taka łatwa bez przerywania implementacji klienta;
• Styl RPC nie ujawnia niczego poza punktami końcowymi procedury + argumentami procedury. Klient nie może określić, co można zrobić dalej.

Z drugiej strony w stylu REST bardzo łatwo jest poprowadzić klientów, włączając informacje kontrolne do reprezentacji (nagłówki HTTP + reprezentacja). Na przykład:

• Możliwe jest (i faktycznie obowiązkowe) osadzanie linków opatrzonych adnotacjami z typami relacji linków, które przekazują znaczenia tych URI;
• Implementacje klienta nie muszą zależeć od konkretnych nazw procedur i argumentów. Zamiast tego klienci zależą od formatów wiadomości. Stwarza to możliwość wykorzystania już zaimplementowanych bibliotek dla określonych formatów mediów (np. Atom, HTML, Collection + JSON, HAL itp.)
• Możliwe jest łatwe zmienianie identyfikatorów URI bez niszczenia klientów, o ile zależą one tylko od zarejestrowanych (lub specyficznych dla domeny) relacji między linkami;
• Możliwe jest osadzenie struktur podobnych do formularzy w reprezentacjach, dając klientom możliwość ujawnienia tych opisów jako funkcji interfejsu użytkownika, jeśli użytkownik końcowy jest człowiekiem;
• Obsługa buforowania jest dodatkową zaletą;
• Standaryzowane kody stanu;

Istnieje wiele innych różnic i zalet po stronie REST.

Zbadałem ten problem bardziej szczegółowo i zdecydowałem, że czysty REST jest zbyt ograniczający, a RPC jest najlepszy, mimo że większość moich aplikacji to aplikacje CRUD. Jeśli pozostaniesz przy REST, w końcu będziesz drapał się w głowie, zastanawiając się, jak możesz łatwo dodać kolejną potrzebną metodę do API w jakimś specjalnym celu. W wielu przypadkach jedynym sposobem na to za pomocą REST jest utworzenie dla niego innego kontrolera, co może nadmiernie skomplikować twój program.

Jeśli zdecydujesz się na RPC, jedyną różnicą jest to, że wyraźnie określasz czasownik jako część identyfikatora URI, który jest wyraźny, spójny, mniej błędny i naprawdę nie sprawia problemów. Zwłaszcza jeśli tworzysz aplikację, która wykracza poza zwykły CRUD, RPC to jedyna droga. Mam inny problem z RESTful purists: HTTP POST, GET, PUT, DELETE mają określone znaczenia w HTTP, które zostały odwrócone przez REST w celu oznaczenia innych rzeczy, po prostu dlatego, że pasują one przez większość czasu - ale nie przez cały czas.

W programowaniu już dawno odkryłem, że próba użycia jednej rzeczy oznacza, że ​​dwie rzeczy kiedyś się pojawią i cię ugryzą. Lubię mieć możliwość używania POST do prawie każdej akcji, ponieważ zapewnia swobodę wysyłania i odbierania danych zgodnie z potrzebami twojej metody. Nie możesz zmieścić całego świata w CRUD.

Po pierwsze, HTTP-REST jest architekturą „reprezentatywnego transferu stanu”. Oznacza to wiele interesujących rzeczy:

• Interfejs API będzie bezstanowy, a zatem znacznie łatwiejszy do zaprojektowania (naprawdę łatwo zapomnieć o przejściu w złożonym automacie) i zintegrować go z niezależnymi częściami oprogramowania.
• Zostaniesz poproszony o zaprojektowanie metod odczytu jako bezpiecznych , które będą łatwe do buforowania i zintegrowania.
• Zostaniesz poprowadzony do zaprojektowania metod pisania jako idempotentnych , które znacznie lepiej poradzą sobie z limitami czasu.

Po drugie, HTTP-REST jest w pełni zgodny z HTTP (patrz „bezpieczny” i „idempotent” w poprzedniej części), dlatego będziesz mógł ponownie używać bibliotek HTTP (istniejących dla każdego istniejącego języka) i zwrotnych serwerów proxy HTTP, co da ci możliwość implementacji zaawansowanych funkcji (pamięć podręczna, uwierzytelnianie, kompresja, przekierowanie, przepisywanie, rejestrowanie itp.) z zerową linią kodu.

Wreszcie, zdaniem projektanta HTTP 1.1 (i wynalazcy REST) ​​użycie HTTP jako protokołu RPC to ogromny błąd: http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation. htm # sec_6_5_2

Świetne odpowiedzi - chciałem tylko wyjaśnić niektóre komentarze. JSON-RPC jest szybki i łatwy w użyciu, ale jak wspomniano, zasoby i parametry są ściśle powiązane i zwykle polegają na czasownikach (api / deleteUser, api / addUser) przy użyciu GET / POST, ponieważ REST zapewnia luźno powiązane zasoby (api / użytkownicy), że w interfejsie API REST HTTP korzysta z kilku metod HTTP (GET, POST, PUT, PATCH, DELETE). REST jest nieco trudniejszy do wdrożenia dla niedoświadczonych programistów, ale styl ten stał się teraz dość powszechnym miejscem i zapewnia znacznie większą elastyczność w dłuższej perspektywie (dając API dłuższą żywotność).

Oprócz tego, że nie ma ściśle powiązanych zasobów, REST pozwala także uniknąć zaangażowania się w jeden typ zawartości - oznacza to, że jeśli twój klient musi odbierać dane w formacie XML, JSON, a nawet YAML - jeśli jest wbudowany w twój system, możesz zwraca dowolną z tych, które używają nagłówków content-type / accept.

Dzięki temu interfejs API jest wystarczająco elastyczny, aby obsługiwać nowe typy zawartości LUB wymagania klienta.

Ale to, co naprawdę odróżnia REST od JSON-RPC, to to, że jest zgodny z serią starannie przemyślanych ograniczeń, zapewniając elastyczność architektoniczną. Ograniczenia te obejmują zapewnienie, że klient i serwer mogą ewoluować niezależnie od siebie (możesz wprowadzać zmiany bez zepsucia aplikacji klienta), połączenia są bezstanowe (stan jest reprezentowany przez hipermedia), zapewniony jest jednolity interfejs do interakcji, interfejs API został opracowany w systemie warstwowym, a odpowiedź jest buforowana przez klienta. Istnieje również opcjonalne ograniczenie dostarczania kodu na żądanie.

Jednak z tym wszystkim powiedziane - MOST API nie są RESTful (zgodnie z Fieldingiem), ponieważ nie zawierają hipermediów (osadzone łącza hipertekstowe w odpowiedzi, które pomagają nawigować po API). Większość interfejsów API, które można znaleźć, jest podobnych do REST, ponieważ są zgodne z większością pojęć REST, ale ignorują to ograniczenie. Jednak coraz więcej interfejsów API implementuje to i staje się coraz bardziej praktyką głównego nurtu.

Daje to również pewną elastyczność, ponieważ interfejsy API sterowane przez hipermedia (takie jak Stormpath) kierują klienta do identyfikatorów URI (co oznacza, że ​​jeśli coś się zmieni, w niektórych przypadkach można zmodyfikować identyfikator URI bez negatywnego wpływu), podobnie jak w przypadku identyfikatorów URI RPC statyczny. W przypadku RPC konieczne będzie także obszerne udokumentowanie różnych identyfikatorów URI i wyjaśnienie, w jaki sposób działają one względem siebie.

Ogólnie rzecz biorąc, powiedziałbym, że REST jest dobrym rozwiązaniem, jeśli chcesz zbudować elastyczny, elastyczny interfejs API, który będzie trwały. Z tego powodu powiedziałbym, że jest to droga do pokonania w 99% przypadków.

Powodzenia, Mike

IMO, kluczowym punktem jest orientacja na akcję a zasoby. REST jest zorientowany na zasoby i dobrze pasuje do operacji CRUD, a biorąc pod uwagę jego znaną semantykę, zapewnia pewną przewidywalność pierwszemu użytkownikowi, ale po zaimplementowaniu z metod lub procedur zmusza do zapewnienia sztucznego tłumaczenia świata skoncentrowanego na zasobach. Z drugiej strony RPC doskonale pasuje do interfejsów API zorientowanych na działanie, w których udostępniasz usługi, a nie zestawy zasobów zgodne z CRUD.

Bez wątpienia REST jest bardziej popularny, to zdecydowanie dodaje pewne punkty, jeśli chcesz udostępnić API osobom trzecim.

Jeśli nie (na przykład w przypadku tworzenia interfejsu AJAX w SPA), moim wyborem jest RPC. W szczególności JSON-RPC, w połączeniu ze schematem JSON jako językiem opisu, i przesyłany przez HTTP lub Websockets w zależności od przypadku użycia.

JSON-RPC to prosta i elegancka specyfikacja, która definiuje ładunki JSON żądania i odpowiedzi do użycia w synchronicznym lub asynchronicznym RPC.

Schemat JSON to projekt specyfikacji definiujący format oparty na JSON, mający na celu opisanie danych JSON. Opisując komunikaty wejściowe i wyjściowe usługi za pomocą schematu JSON, możesz mieć dowolną złożoność struktury komunikatów bez uszczerbku dla użyteczności, a integrację usług można zautomatyzować.

Wybór protokołu transportowego (HTTP a gniazda sieciowe) zależy od różnych czynników, przy czym najważniejsze jest to, czy potrzebujesz funkcji HTTP (buforowanie, rewalidacja, bezpieczeństwo, idempotencja, typ zawartości, wieloczęściowy, ...), czy też aplikacja wymaga wymiany wiadomości o wysokiej częstotliwości.

Do tej pory jest to moja osobista opinia na ten temat, ale teraz coś, co może być naprawdę pomocne dla programistów Java, którzy czytają te linie, ramy, nad którymi pracowałem przez ostatni rok, zrodzone z tego samego pytania, które zastanawiasz się teraz :

http://rpc.brutusin.org

Tutaj możesz zobaczyć demo na żywo, pokazujące wbudowaną przeglądarkę repozytoriów do testowania funkcjonalnego (dzięki Schemat JSON) i szereg przykładowych usług:

http://demo.rpc.brutusin.org

Mam nadzieję, że to pomaga w kryciu!

Nacho

Jeśli Twoja usługa działa poprawnie tylko z modelami i wzorcem GET / POST / PUT / DELETE, użyj czystego REST.

Zgadzam się, że HTTP został pierwotnie zaprojektowany dla aplikacji bezstanowych.

Ale w przypadku nowoczesnych, bardziej złożonych (!) Aplikacji w czasie rzeczywistym (internetowych), w których będziesz chciał używać Websockets (co często oznacza stanowość), dlaczego nie skorzystać z obu? JSON-RPC przez Websockets jest bardzo lekki, więc masz następujące zalety:

• Natychmiastowe aktualizacje na każdym kliencie (zdefiniuj własne wywołanie RPC między serwerami w celu aktualizacji modeli)
• Łatwe dodawanie złożoności (spróbuj zrobić klon Etherpad tylko z REST)
• Jeśli zrobisz to dobrze (dodaj RPC tylko jako dodatek w czasie rzeczywistym), większość nadal będzie dostępna tylko z REST (z wyjątkiem jeśli główną funkcją jest czat lub coś takiego)

Ponieważ projektujesz tylko interfejs API po stronie serwera, zacznij od zdefiniowania modeli REST, a następnie dodaj obsługę JSON-RPC w razie potrzeby, ograniczając liczbę wywołań RPC do minimum.

(i przepraszamy za nadużywanie nawiasów)

W przeszłości byłem wielkim fanem REST i ma on wiele zalet w porównaniu z RPC na papierze. Możesz zaprezentować klientowi różne typy zawartości, buforowanie, ponowne użycie kodów stanu HTTP, poprowadzić klienta przez interfejs API i osadzić dokumentację w interfejsie API, jeśli nie jest to w większości samo-wyjaśniające się.

Ale z mojego doświadczenia wynika, że ​​w praktyce to nie wytrzymuje, a zamiast tego wykonujesz wiele niepotrzebnej pracy, aby wszystko było w porządku. Ponadto kody stanu HTTP często nie są odwzorowane dokładnie na logikę domeny, a używanie ich w kontekście często wydaje się nieco wymuszone. Ale najgorsze w REST jest, moim zdaniem, to, że spędzasz dużo czasu na projektowaniu swoich zasobów i interakcji, na które pozwalają. I ilekroć wprowadzisz kilka ważnych dodatków do swojego API, masz nadzieję, że znajdziesz dobre rozwiązanie, aby dodać nową funkcjonalność i nie zaprojektowałeś się już w kącie.

Często wydaje mi się to stratą czasu, ponieważ przez większość czasu mam już doskonale doskonały i oczywisty pomysł na temat modelowania interfejsu API jako zestawu zdalnych wywołań procedur. A jeśli dołożyłem wszelkich starań, aby modelować mój problem w ramach ograniczeń usługi REST, następnym problemem jest jak wywołać go od klienta? Nasze programy opierają się na procedurach wywoływania, więc zbudowanie dobrej biblioteki klienta RPC jest łatwe, zbudowanie dobrej biblioteki klienta REST nie jest tak bardzo, a w większości przypadków po prostu mapujesz z interfejsu API REST na serwerze na zestaw procedur w twoim kliencie biblioteka.

Z tego powodu RPC wydaje mi się dziś o wiele prostsze i bardziej naturalne. To, czego tak naprawdę brakuje, to spójne środowisko, które ułatwia pisanie usług RPC, które są samoopisujące i interoperacyjne. Dlatego stworzyłem własny projekt, aby eksperymentować z nowymi sposobami na ułatwienie RPC i być może ktoś też uzna to za przydatne: https://github.com/aheck/reflectrpc

Według modelu dojrzałości Richardsona pytanie nie brzmi REST vs. RPC , ale ile REST ?

W tym widoku zgodność ze standardem REST można podzielić na 4 poziomy.

• poziom 0: myśl w kategoriach działań i parametrów. Jak wyjaśnia artykuł, jest to zasadniczo odpowiednik JSON-RPC (artykuł wyjaśnia to dla XML-RPC, ale te same argumenty dotyczą obu).
• poziom 1: myśl w kategoriach zasobów. Wszystko, co dotyczy zasobu, należy do tego samego adresu URL
• poziom 2: użyj czasowników HTTP
• poziom 3: HATEOAS

Według twórcy standardu REST tylko usługi poziomu 3 można nazwać RESTful. Jest to jednak wskaźnik zgodności , a nie jakości. Jeśli chcesz tylko wywołać funkcję zdalną, która wykonuje obliczenia, prawdopodobnie nie ma sensu mieć w odpowiedzi odpowiednich łączy hipermedialnych, ani różnicowania zachowania na podstawie użytego czasownika HTTP. Tak więc takie wezwanie jest z natury bardziej podobne do RPC. Jednak niższy poziom zgodności niekoniecznie oznacza stanowość lub wyższy stopień sprzężenia. Prawdopodobnie zamiast myśleć REST vs. RPC , powinieneś użyć jak największej ilości REST, ale nie więcej. Nie przekręcaj aplikacji tak, aby pasowała do standardów zgodności RESTful.

Dlaczego JSON RPC:

W przypadku interfejsów API REST musimy zdefiniować kontroler dla każdej potrzebnej funkcji / metody. W rezultacie, jeśli mamy 10 metod, które chcemy, aby były dostępne dla klienta, musimy napisać 10 kontrolerów, aby połączyć żądanie klienta z określoną metodą.

Innym czynnikiem jest to, że chociaż mamy różne kontrolery dla każdej metody / funkcji, klient musi pamiętać, aby użyć POST lub GET. To jeszcze bardziej komplikuje sytuację. Ponadto, aby wysłać dane, należy ustawić typ treści żądania, jeśli używany jest test POST.

W przypadku JSON RPC sprawy są znacznie uproszczone, ponieważ większość serwerów JSONRPC działa na metodach POST HTTP, a typem zawartości jest zawsze application / json. To odciąża pamięć od używania właściwej metody HTTP i ustawień treści po stronie klienta.

Nie trzeba tworzyć osobnych kontrolerów dla różnych metod / funkcji, które serwer chce udostępnić klientowi.

Dlaczego REST:

Masz oddzielne adresy URL dla różnych funkcji, które serwer chce udostępnić po stronie klienta. W rezultacie możesz osadzić te adresy URL.

Większość z tych kwestii jest dyskusyjna i całkowicie zależy od potrzeby osoby.

Myślę, że jak zawsze zależy ...

REST ma ogromną zaletę powszechnego wsparcia publicznego, a to oznacza wiele narzędzi i książek. Jeśli chcesz stworzyć interfejs API, który jest używany przez dużą liczbę konsumentów z różnych organizacji, jest to sposób, aby przejść tylko z jednego powodu: jest popularny. Jako protokół jest to oczywiście całkowita awaria, ponieważ istnieje zbyt wiele zupełnie różnych sposobów mapowania polecenia na adres URL / czasownik / odpowiedź.

Dlatego, gdy piszesz aplikację internetową z jedną stroną, która musi rozmawiać z backendem, myślę, że REST jest zbyt skomplikowany. W tej sytuacji nie musisz martwić się o długoterminową kompatybilność, ponieważ aplikacja i interfejs API mogą ewoluować razem.

Kiedyś zacząłem od REST dla aplikacji z jedną stroną, ale drobnoziarniste polecenia między aplikacją a serwerem szybko doprowadziły mnie do szału. Czy powinienem zakodować go jako parametr ścieżki? W ciele? Parametr zapytania? Nagłówek? Po zaprojektowaniu adresu URL / czasownika / odpowiedzi musiałem zakodować ten bałagan w JavaScript, dekoder w Javie, a następnie wywołać rzeczywistą metodę. Chociaż istnieje wiele narzędzi do tego, naprawdę trudno jest nie uzyskać semantyki HTTP w kodzie domeny, co jest naprawdę złą praktyką. (Spójność)

Spróbuj utworzyć plik Swagger / OpenAPI dla średnio złożonej witryny i porównaj go z pojedynczym interfejsem Java opisującym zdalne procedury w tym pliku. Wzrost złożoności jest oszałamiający.

W związku z tym przestawiłem się z REST na JSON-RPC dla aplikacji jednostronicowej. a. Opracowałem maleńką bibliotekę, która zakodowała interfejs Java na serwerze i wysłałem go do przeglądarki. W przeglądarce utworzono proxy dla kodu aplikacji, który zwrócił obietnicę dla każdej funkcji.

Ponownie, REST ma swoje miejsce tylko dlatego, że jest sławny i dlatego jest dobrze obsługiwany. Ważne jest również uznanie podstawowej filozofii zasobów bezpaństwowych i modelu hierarchicznego. Jednak zasady te można równie łatwo zastosować w modelu RPC. JSON RPC działa przez HTTP, więc ma te same zalety REST w tym obszarze. Różnica polega na tym, że gdy nieuchronnie natrafisz na te funkcje, które nie są dobrze odwzorowane na te zasady, nie jesteś zmuszony do wykonywania zbyt dużej ilości niepotrzebnej pracy.

REST jest ściśle powiązany z HTTP, więc jeśli udostępniasz swój interfejs API tylko przez HTTP, REST jest bardziej odpowiedni dla większości (ale nie wszystkich) sytuacji. Jeśli jednak chcesz udostępnić swój interfejs API w innych transportach, takich jak wiadomości lub gniazda sieciowe, REST po prostu nie ma zastosowania.

Lepiej byłoby wybrać JSON-RPC między REST i JSON-RPC, aby opracować interfejs API dla aplikacji WWW, który będzie łatwiejszy do zrozumienia. JSON-RPC jest preferowany, ponieważ jego mapowanie na wywołania metod i komunikację można łatwo zrozumieć.

Wybór najbardziej odpowiedniego podejścia zależy od ograniczeń lub głównego celu. Na przykład, o ile wydajność jest główną cechą, wskazane jest wybranie JSON-RPC (na przykład High Performance Computing). Jeśli jednak głównym celem jest agnostyka w celu zaoferowania ogólnego interfejsu, który można wywnioskować przez innych, wskazane jest skorzystanie z usługi REST. Jeśli oba cele są potrzebne do osiągnięcia, zaleca się włączenie obu protokołów.

Faktem, który faktycznie dzieli REST od JSON-RPC, jest to, że śledzi szereg starannie przemyślanych ograniczeń potwierdzających elastyczność architektoniczną. Ograniczenia polegają na zapewnieniu, że zarówno klient, jak i serwer są w stanie rosnąć niezależnie od siebie (zmiany można wprowadzać bez bałaganu przy zastosowaniu klienta), połączenia są bezstanowe (stan jest uważany za hipermedia), jednolity interfejs jest oferowany do interakcji, interfejs API jest zaawansowany w systemie warstwowym (Hall, 2010). JSON-RPC jest szybki i łatwy w użyciu, jednak ponieważ wspomniane zasoby oraz parametry są ściśle powiązane i prawdopodobnie zależy od czasowników (api / addUser, api / deleteUser) przy użyciu GET / POST, podczas gdy REST dostarcza luźno powiązane zasoby (api / users) w HTTP. Interfejs API REST zależy od kilku metod HTTP, takich jak GET, PUT, POST, DELETE, PATCH.

JSON (oznaczony jako JavaScript Object Notation), będący lekkim formatem wymiany danych, jest łatwy do odczytania i zapisu przez ludzi. Maszyny mogą bezproblemowo analizować i generować. JSON jest formatem tekstowym, który jest całkowicie niezależny od języka, ale ćwiczy konwencje znane programistom z rodziny języków, składającym się z C #, C, C ++, Java, Perl, JavaScript, Python i wielu innych. Takie właściwości sprawiają, że JSON jest doskonałym językiem wymiany danych i lepszym wyborem.

Błędne pytanie: narzuca manichean, który nie istnieje!

Możesz używać JSON-RPC z „mniej czasownikiem” (bez metody ) i zachować minimalną standaryzację niezbędną dla sendo id, parametrów, kodów błędów i komunikatów ostrzegawczych . Standard JSON-RPC nie mówi „nie możesz być REST”, tylko mówi, jak spakować podstawowe informacje.

„REST JSON-RPC” istnieje ! jest REST z „najlepszymi praktykami”, dla minimalnego pakowania informacji, z prostymi i solidnymi umowami.

Przykład

(z tej odpowiedzi i kontekstu dydaktycznego)

W przypadku REST zazwyczaj pomaga zacząć od myślenia o zasobach. W tym przypadku zasób nie jest tylko „kontem bankowym”, ale jest transakcją tego konta bankowego ... Ale JSON-RPC nie zobowiązuje parametru „metoda”, wszystkie są kodowane przez „ścieżkę” punktu końcowego.

• REST Depozyt z POST /Bank/Account/John/Transactionprośbą JSON {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
  Odpowiedź JSON może być jak{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• REST Wycofaj z POST /Bank/Account/John/Transaction... podobnie.

• ... GET /Bank/Account/John/Transaction/12345@13... Może to zwrócić rekord JSON dokładnie tej transakcji (np. Twoi użytkownicy na ogół chcą zapisów obciążeń i kredytów na swoim koncie). Coś jak {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. Konwencja dotycząca żądania (REST) ​​GET może obejmować kodowanie id przez „@id”, więc nie trzeba wysyłać żadnych JSON, ale nadal używać JSON-RPC w pakiecie odpowiedzi.

Jeśli poprosisz o zasoby, interfejs API RESTful jest lepszy z założenia. Jeśli zażądasz skomplikowanych danych z wieloma parametrami i skomplikowanymi metodami innymi niż zwykła CRUD, RPC jest właściwą drogą.

Używam vdata dla protokołu RPC: http://vdata.dekuan.org/

1, PHP i JavaScript są w porządku. 2, połączenie udostępniania między źródłami (CORS) jest nadal w porządku.