REST vs JSON-RPC? [Zamknięte]

251

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.

Ali Shakiba
źródło
29
REST jest obecnie zdecydowanie popularną odpowiedzią. Nie jestem jednak przekonany, że zawsze jest to właściwa odpowiedź. Może wystąpić niedopasowanie impedancji między zorientowanym na zasoby interfejsem API REST a domeną problemów, która jest z natury oparta na zadaniach lub przepływie pracy. Jeśli stwierdzisz, że musisz wykonać różne typy PATCHÓW dla tego samego zasobu lub że niektóre zadania nie są mapowane na konkretny zasób, musisz zacząć zginać paradygmat REST. Czy używasz akcji / poleceń jako zasobów? Czy rozróżniasz typy poleceń w nagłówku Content-Type jako parametry? Nie jestem pewien, czy istnieje jedna uniwersalna odpowiedź.
Landon Poch
27
JSON-RPC jest prosty i spójny, sprawia przyjemność.
dnault
1
W sierpniu 2015 roku wdrożyłem zarówno klienta, jak i serwer przy użyciu REST, pierwsze 2 dni uczyłem się, a potem zrozumiałem, dlaczego jest popularny. To była prawdziwa radość po utworzeniu małej aplikacji, klient naprawdę nie ma pracy, aby zapamiętać różne ścieżki URL, serwer w node.js i klient w javascript mają tę samą strukturę (ścieżki URL) do komunikacji. Łał! był bardzo szybki, produkt został dostarczony w zaledwie 15 dni, nawet pisząc od zera. REST to dobra droga. Zauważ też, że Popular Apache CouchDB korzysta z REST, świetnej bazy danych, jest bardzo dumna, że ​​zrobiła to również w REST. W skrócie, REST jest PRAWY (poprawny) z czystym interfejsem.
Manohar Reddy Poreddy
6
To zależy od ograniczeń, które masz lub twojego głównego celu. Na przykład, jeśli głównym aspektem jest wydajność, możesz wybrać JSON-RPC (np. High Performance Computing). Jeśli twoim głównym celem jest agnostyka, aby zapewnić ogólny interfejs do interpretacji przez innych, twoją drogą jest REST. Jeśli chcesz obu celów, musisz dołączyć oba protokoły. Twoje potrzeby określają rozwiązanie.
Stathis Andronikos
@StathisAndronikos Masz rację, moim głównym celem była łatwość użycia i dobra wydajność aplikacji internetowych (nie HPC).
Ali Shakiba

Odpowiedzi:

221

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.

ioseb
źródło
20
Co rozumiesz przez „obowiązkowe jest osadzanie linków opatrzonych adnotacjami z typami relacji linków, które przekazują znaczenia…”?
pjz
129
„Klienci muszą znać nazwy procedur” - to nie jest argument, ponieważ w REST ta nazwa jest zapisana na stałe w URI zamiast przekazywana jako parametr. W przeciwnym razie serwer nie będzie wiedział, którą metodę powinien wykonać.
Centurion
44
„Zmiana podpisów procedur nie jest taka łatwa ... po stronie serwera bez zepsucia implementacji klienta”, jest to również dyskusyjne. Zarówno REST, jak i JSON-RPC nie są SOAP i nie mają WSDL, który opisuje istniejące usługi sieciowe i ich typy, dzięki czemu można ich używać do dynamicznej zmiany po stronie klienta. Tak czy inaczej, jeśli zmienisz usługę internetową, musisz zmienić klienta. W przeciwnym razie musisz skorzystać z SOAP.
Centurion
64
Zakodowałem dosen aplikacji i jeszcze nie widziałem żadnych elastycznych usług internetowych. W przypadku zmiany zaplecza i usług internetowych klient zawsze musi zostać refaktoryzowany / zaktualizowany w celu dopasowania do nowych wymagań. Wspomniałem o SOAP i ponieważ ma on coś, co daje elastyczność, np. WSDL, dzięki czemu można coś zautomatyzować i mieć większą elastyczność, ponieważ można uzyskać informacje o zestawie wyników, typach danych i dostępnych usługach internetowych. REST i inni wcale tego nie mają. Tak więc ani REST, ani JSON-RPC, ani inny typ usługi internetowej nie dadzą magii, która wyeliminowałaby potrzebę ręcznej aktualizacji klienta.
Centurion
15
Dla mnie, mojego obecnego zespołu i poprzednich zespołów, usługi sieciowe RESTful są przeznaczone dla aplikacji typu CRUD. Odnośnie do „Czy przepisujemy przeglądarki za każdym razem, gdy coś się zmienia na serwerze?” - nie, ponieważ przeglądarki są tylko programami wykonawczymi HTTP, nie mają nic wspólnego z logiką biznesową, którą program kliencki musi wdrożyć (pokazywać ekrany, wykonywać podobne czynności). Wygląda na to, że rozpoczęliśmy wojnę z ogniem, ale ogólnie chciałbym mieć inne solidne źródło usług internetowych RESTfull z praktycznym przepływem użytkowania, z magiczną elastycznością, o której mówisz. Tymczasem wiele stwierdzeń jest zbyt niejasnych.
Centurion
163

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.

Bruce Patin
źródło
30
Ta odpowiedź pokazuje zbyt często błędne wyobrażenie o tym, czym tak naprawdę jest REST. REST to zdecydowanie nie tylko mapowanie CRUD na metody HTTP. Pomysł, że problemem jest „dodać inną metodę”, wyraźnie wskazuje, że REST jest źle rozumiany jako RPC przez HTTP, co wcale nie jest. Spróbuj przeczytać blog Roy'a Fieldingsa lub jego rozprawę - Google pomoże ci go znaleźć - w swojej odpowiedzi w ogóle nie opisujesz REST.
nepdev
68
Jestem bardzo praktyczną osobą. Wszystkie opisy REST, które przeczytałem, zaczynają się od mapowania CRUD na metody HTTP. Można dodawać więcej teoretycznie, ale w praktyce nie. Na przykład ostatnio chciałem zaimplementować PATCH dla urządzeń z Androidem, ale odkryłem, że Android nie zezwala na PATCH, więc użyłem POST z wyraźnie zdefiniowaną akcją w tym celu w URI. Zasadniczo czysty REST nie wykona zadań, których potrzebuję, więc używam tego, co działa.
Bruce Patin,
4
Więc @BrucePatin, w swojej wersji „REST” masz kontroler z czterema publicznymi metodami, które mapują 1 na 1 za pomocą GET | PUT | POST | DELETE? Niektóre frameworki to robią, ale to nie jest REST. Czasowniki HTTP zawierają niejasne abstrakcyjne twierdzenia dotyczące semantyki danego żądania. Musisz odpowiednio zamapować punkty końcowe na te klasy. GET może mapować do wielu różnych punktów końcowych, podobnie jak inne. W rzeczywistości nie ma powodu, dla którego nie można zaimplementować pełnego REST JSON-RPC przez HTTP.
spinkus
5
Jest bardzo dobry powód. Mogę potrzebować kilkudziesięciu działań i już korzystałem ze wspólnego zastosowania (Android), które nawet nie obsługuje PATCH. To zabija to zimno. Wolę być konsekwentny niż mieć do czynienia z kilkoma wyjątkami od reguły. Ogólnie rzecz biorąc, będę teraz używać tylko GET, POST i DELETE. PUT nie zezwala na informacje zwrotne, które chciałbym uzyskać podczas operacji aktualizacji. Używam POST do prawie wszystkiego. Jeśli chodzi o buforowanie, spowodowało wiele problemów ze zwrotem starych danych. Jeśli chodzi o umieszczanie parametrów w POST, ASP.NET już obsługuje je automatycznie z automatycznych obiektów JSON.
Bruce Patin,
22
Uważam, że kłótnie o to, czym tak naprawdę jest REST, tylko podkreślają twoje komentarze i podkreślają poważną wadę REST. Koncepcyjnie trudno jest znaleźć dwie osoby, które całkowicie zgadzają się co do tego, czym jest RESTful. W każdym razie nie ma to znaczenia, ponieważ żadna usługa nie powinna przejść nieudokumentowanej RPC lub REST. Jeśli jest to udokumentowane, programista, który go używa, nie powinien mieć problemów.
Agile Jedi
29

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

Aurélien
źródło
1
+1 za wiarygodne odniesienie do faceta, który powinien wiedzieć ... Trudno potem argumentować za RPC przez HTTP, nie uznając tego za hack / obejście ...
RJB
9
Właśnie przywołałeś coś z 2000 roku. Jest to bardziej filozoficzny argument przemawiający za REST kontra RPC. Semantycznie i stosując wzorzec RPC można łatwo uznać URI za „procedurę”, a zakodowane parametry za… no cóż… parametry. Każdy wzorzec działałby dobrze w przypadku HTTP. To samo z SOAP, RAILS lub inną liczbą wzorców / protokołów, które zostały nałożone na HTTP. Nie ma to znaczenia, o ile oferujesz spójny interfejs API, który nie zrywa umowy.
Agile Jedi
Aurélien, czy możesz uzasadnić, dlaczego REST jest łatwiejszy do zintegrowania z niezależnymi częściami oprogramowania? Dla mnie, bez względu na to, czy używasz RESTful API czy RPC, oprogramowanie klienckie musi znać format, w którym mówi Twój interfejs API.
Alexey
1
@Alexey Ten argument dotyczył bezpaństwowości. Łatwiej jest integrować się ekspres do kawy, którego API jest CREATE CUP, niż inna, która będzie zawierać INSERT COIN, SELECT COFFEE, SELECT SUGAR, i START. W drugim API, ponieważ zależy to od stanu komputera, musisz być bardzo ostrożny z sekwencją wywołań procedur.
Aurélien
1
HTTP jako protokół RPC to REST. Twoja nieprawidłowa interpretacja jest szokująco odwrotna.
Tiberiu-Ionuț Stan
24

Ś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

Mike Stowe
źródło
3
to nie jest LECZNIE trudniejsze, ale raczej niezwykle trudniejsze. Próbowałem to zrozumieć przez około 4 miesiące i nadal nie mam dobrego pojęcia, jak napisać usługę, która nie przekształci się w bezpaństwowe RPC przez HTTP przy użyciu JSON, I nadal nie jestem przekonany istnieje prawdziwa różnica między „REST” a tym, co właśnie powiedziałem
Austin_Anderson
19

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

idelvall
źródło
Wspaniale jest znaleźć pokrewnego ducha! Pracuję nad czymś podobnym tutaj: github.com/dnault/therapi-json-rpc
dnault
:)
Zajmę
1
Zgadzam się z tym. REST działa dobrze dla interfejsów API CRUD, ponieważ masz oczywiste POST / GET / PUT / DELETE [PoGPuD? ;)] mapowanie. Jeśli jednak twój interfejs API nie pasuje do tych czasowników, JSON-RPC może być dobrym rozwiązaniem, ponieważ czasowniki po prostu mylą sprawy. Więc tak, kto go używa i dlaczego jest tak ważnym czynnikiem.
Algy Taylor,
1
Dokładnie - REST to królestwo rzeczowników, JSON-RPC to czasowniki.
Rob Grant
16

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)

cbix
źródło
15

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

ahe
źródło
Sprawdź OpenRPC, powinien on zaspokoić twoją potrzebę „łatwych do pisania usług RPC, które są samoopisujące i interoperacyjne”
Belfordz
11

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.

niebieska notatka
źródło
1
+1 dla poziomów 0, 1 i 2. Jednak nigdy nie widziałem udanego wdrożenia HATEOS, ale widziałem dwie niefortunnie nieudane próby.
mjhm
8

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.

Umer Farooq
źródło
3

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.

Peter Kriens
źródło
1
Ta odpowiedź uświadomiła mi podobieństwa między GraphQL a JSON-RPC i dlaczego GraphQL staje się popularnym wyborem dla SPA.
Dennis
OpenRPC jest odpowiednikiem OpenAPI / Swagger, ale dla JSON-RPC
Belfordz
1

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.

dtoux
źródło
2
REST jest stylem architektonicznym i nie zależy od protokołu.
Mark Cidade
4
Masz rację REST to zasada architektoniczna. Jednak na jego teoretyczne podstawy duży wpływ miał protokół HTTP i pomimo twierdzenia o uniwersalnym zastosowaniu nie znalazł praktycznego zastosowania poza domeną internetową. Można więc śmiało powiedzieć, że gdy ktoś wspomina o REST, odnosi się do usług internetowych, a nie do zasady architektury.
dtoux
1

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.

SinghKunal
źródło
Proces
1

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.

Peter Krauss
źródło
Zobacz także stackoverflow.com/a/13952665/287948
Peter Krauss
0

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ą.

Adrian Liu
źródło
Jest to bardzo duże uproszczenie tematu. Dlaczego konkretnie jest to „Lepsze z założenia”? JSON-RPC może być tak prosty lub tak skomplikowany, jak chcesz, więc argument, że jest on „lepszy” dla „wielu parametrów i skomplikowanych metod” jest również fałszywy. W tej kwestii nie jest ani lepszy ani gorszy.
Belfordz
Nie ma znaczenia, czy RPC używa JSON, protobuf lub XML do serializacji danych. Kluczowym punktem jest API, jak powiedziałem. Nie mam na myśli, że jedno jest lepsze od drugiego we wszystkich przypadkach. Ale myślę, że parametry i metody mają znaczenie, kiedy wybierasz między dwiema implementacjami. Jeśli są one proste, większość programistów dobrze rozumie API RESTful i można łatwo zbudować żądanie http. Jeśli są skomplikowane, RPC jest w stanie wyrazić takie interfejsy API, a twoje IDE i kompilator mogą ci w tym pomóc.
Adrian Liu
-1

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.

Liu Qixing
źródło