REST został zaprojektowany dla Internetu, a sieć została zaprojektowana dla REST. Oba pasujące po prostu pasują do siebie. Praca doktorska Roya Fieldinga z 2000 r. Style architektoniczne i projektowanie architektur oprogramowania sieciowego zdefiniowały i wprowadziły pojęcie REST , a sieć i REST są w znacznym stopniu powiązane: Roy Fielding pracował nad HTTP / 1.1, którego jest głównym autorem, i wykorzystał to, czego się tam nauczył, aby opisać REST w swojej rozprawie.
Tak więc prostym powodem, dla którego sieć i REST są tak dobrze ze sobą powiązane, jest to, że definicja REST została wyodrębniona z tego, jak działa sieć, a sieć jest implementacją REST.
Właśnie dlatego REST dobrze nadaje się do usług internetowych i aplikacji internetowych: ponieważ po prostu robisz te same rzeczy, które już udowodniono, że działają w „ludzkiej” sieci i stosujesz je w sieci „maszynowej”.
Duży problem z RPC (w zależności od dokładnej realizacji) leży w zasadzie w błędom Distributed Computing , które zostały wyjaśnione w sposób bardziej szczegółowy w ten oficjalny dokument przez Arnon Rotem-gal Oz :
- Sieć jest niezawodna
- Opóźnienie wynosi zero
- Przepustowość jest nieskończona
- Sieć jest bezpieczna
- Topologia się nie zmienia
- Jest jeden administrator
- Koszt transportu wynosi zero
- Sieć jest jednorodna
Są to wszystkie założenia, które zwykle przyjmują nowi użytkownicy, kiedy zaczynają tworzyć systemy rozproszone. Oczywiście wszystkie z nich są fałszywe. I musisz wziąć je wszystkie pod uwagę przy tworzeniu systemów rozproszonych.
Problem z wieloma implementacjami RPC polega na tym, że starają się, aby połączenia zdalne wyglądały jak połączenia lokalne. Ale nie są niczym:
- połączenie lokalne nigdy nie kończy się niepowodzeniem; podprogram , który nazywa może zawieść, ale rozmowa sama nigdy nie robi - zdalne wywołanie może zgubić się w sieci
- połączenie lokalne jest natychmiastowe; podprogram , który nazywa może działać przez długi czas (lub nawet na zawsze, jeśli utknie w nieskończonej pętli), ale rozmowa sama bierze w ogóle czasu (no, garść instrukcji procesora co najwyżej mniej, jeśli połączenie jest podkreślone, ale jest bardzo szybki) - zdalne połączenie może utknąć w sieci na długi czas
- jeśli podprogram powróci normalnie, wynik zawsze wraca - po zdalnym wywołaniu wynik może zostać utracony w sieci
- zwroty są natychmiastowe - wyniki zdalne mogą długo podróżować w sieci
- jeśli raz wywołam podprogram, uruchomi się dokładnie raz - zdalne połączenie może zostać utracone w sieci lub zduplikowane, więc procedura zdalna może działać od 0 do dowolnej liczby razy
- Otrzymuję dokładnie jeden wynik - zdalny wynik może zostać zgubiony lub zduplikowany, więc możesz uzyskać wynik 0 lub więcej razy
- jeśli dwukrotnie wywołam podprogram, otrzymam dwa wyniki i otrzymam wynik pierwszego wywołania przed wynikiem drugiego wywołania - prawdopodobnie prawdopodobnie już się domyślacie: z RPC możesz nie otrzymać żadnych wyników lub tylko pierwszego , lub tylko druga, druga przed pierwszą lub pierwsza może zostać utracona, a drugą otrzymasz dwa razy, lub odwrotnie, i tak dalej ...
- jeśli zadzwonię,
aa następnie bodzyskam wynik, aa następnie wynik b - to tylko bardziej ogólna wersja poprzedniego punktu, z RPC, możesz uzyskać dowolną z dwóch odpowiedzi 0 lub więcej razy w dowolnej kolejności
Państwo będzie mieć do czynienia z wszystkich wyżej dla zdalnego wywołania. Ale jeśli twoja struktura sprawia, że połączenia zdalne są nierozróżnialne od połączeń lokalnych, nie możesz tego zrobić, ponieważ nie wiesz, które z nich to połączenia zdalne. Framework może próbować obsłużyć je wszystkie, ale problem polega na tym, że framework nie wie tyle o twoim systemie, co ty. Nie wie, czy są połączenia, w których to tak naprawdę nie ma znaczenia, czy ktoś się zgubi raz na jakiś czas. Ramy muszą więc być bardzo defensywne, a to jest kosztowne ze względu na opóźnienia i przepustowość.
Zwłaszcza, że ramy nie mogą cię ochronić. CAP Twierdzenie mówi, że rozproszony system nie może być spójne, dostępne, i partycji-tolerancyjny w tym samym czasie; a dokładniej mówi, że po wystąpieniu partycji system nie może być zarówno spójny, jak i dostępny, musi wybrać jedną (wbrew powszechnemu przekonaniu twierdzenie nie mówi, że nie można mieć wszystkich trzech, gdy system działa) normalnie możesz mieć wszystkie trzy, ale kiedy już masz Partycję, musisz wybrać jedną z dwóch pozostałych). PACELC Twierdzenie rozszerza CAP twierdzenie, pokazując, że nawet, gdy system działa, trzeba kompromis Latency vs. konsystencji.
Są to ważne kompromisy, przed którymi ramy właściwie nie są w stanie cię ochronić, ponieważ są specyficzne dla domeny i ważne dla rdzenia.
Porównajmy to z podejściem jak Erlang, co czyni pracę: w Erlang, wszystkie wiadomości wysyła są traktowane jako odległe, nawet jeśli są one lokalne. Oznacza to, że zawsze jesteś przygotowany na wszystkie powyższe problemy (i wiele innych). Dla procesów lokalnych, te nie stwarzają trochę narzutem, choć. Aby temu zaradzić, istnieje wiele narzędzi, struktur, bibliotek, wzorców i idiomów służących do obsługi błędów i nadzoru.
Nie opisałeś, w jaki sposób działa Twój framework RPC i jakiego języka lub bibliotek używasz, ale mam poważne podejrzenia, że należy on do poprzedniego typu „udawaj, że sieć nie istnieje”. Te po prostu nie działają. To jest w porządku , aby usunąć rozróżnienie połączeń lokalnych i zdalnych traktując wszystko jako zdalnego połączenia. Robiąc to w drugą stronę, zbyt wiele abstrakcji: sieć jest częścią twojego systemu, jeśli ją abstraktujesz, wyodrębniasz coś, o czym naprawdę musisz wiedzieć.
Teraz, czy trzeba specjalnie użyć REST, czy nie, to zupełnie inna kwestia. Jak wyjaśniłem powyżej, sieć została zaprojektowana dla REST, a REST została zaprojektowana dla sieci, więc oba mają sens razem, ale możesz użyć innych stylów architektonicznych, jeśli chcesz. Ale przynajmniej część twojego pytania dotyczyła „dlaczego nie RPC”, a ja przedstawiłem powyższe powody, a dokładniej wyjaśniłem, dlaczego rodzaj RPC, którego podejrzewasz, że używasz, może wpędzić cię w kłopoty.