Kiedy podejścia RPC są bardziej odpowiednie niż REST?

Po obejrzeniu tej rozmowy Steve Vinoski na temat REST, Reuse and Serendipity zastanawiam się, czy istnieją przypadki biznesowe w projektach typu greenfield dla (XML-) konfiguracji RPC, których REST nie mógłby rozwiązać w lepszy sposób.

Kilka problemów RPC, o których wspomina:

• Skoncentruj się na języku (dopasuj system rozproszony do języka, a nie na odwrót)
• „Niech wygląda lokalnie” (i radzi sobie z awariami i opóźnieniami jako wyjątkami, a nie regułą)
• z założenia ma być niezależny od języka, ale nadal ma „wywołania funkcji” w różnych językach jako główny składnik
• Płyta kotła IDL
• Złudzenie bezpieczeństwa typu
• i kilka innych ...

Aby nieco to zobrazować, niektóre wyniki wyszukiwania dynamicznego Google dla RPC vs REST:

Ogólnie rzecz biorąc, RPC oferuje znacznie więcej integracji językowej niż REST. Jak już wspomniałeś, wiąże się to z szeregiem problemów związanych ze skalą, obsługą błędów, bezpieczeństwem typu itp., Szczególnie gdy jeden system rozproszony obejmuje wiele hostów z kodem napisanym w wielu językach. Jednak po napisaniu systemów biznesowych korzystających z RPC, REST, a nawet obu jednocześnie, odkryłem, że istnieją pewne dobre powody, aby w niektórych przypadkach wybierać RPC zamiast REST.

Oto przypadki, w których RPC jest lepszym rozwiązaniem:

• Szczelne połączenie. (Rozproszone) komponenty systemu są zaprojektowane do współpracy, a zmiana jednego prawdopodobnie wpłynie na wszystkie pozostałe. Jest mało prawdopodobne, że komponenty będą musiały zostać dostosowane w celu komunikacji z innymi systemami w przyszłości.
• Niezawodna komunikacja. Komponenty będą komunikować się ze sobą całkowicie na tym samym hoście lub w sieci, w której prawdopodobnie nie wystąpią problemy z opóźnieniami, utrata pakietów itp. (To jednak oznacza, że ​​musisz jednak zaprojektować system tak, aby obsługiwał te przypadki).
• Jednolity język. Wszystkie (lub przeważnie wszystkie) komponenty zostaną napisane w jednym języku. Jest mało prawdopodobne, że dodatkowe komponenty napisane w innym języku zostaną dodane w przyszłości.

Jeśli chodzi o kwestię IDL, w systemie REST musisz także napisać kod, który konwertuje dane w żądaniach REST i odpowiedziach na dowolną używaną wewnętrzną reprezentację danych. Źródła IDL (z dobrymi komentarzami) mogą również służyć jako dokumentacja interfejsu, który należy napisać i utrzymywać osobno dla interfejsu API REST.

Powyższe trzy elementy często występują, gdy chcesz zbudować jeden element większego systemu. Z mojego doświadczenia wynika, że ​​te komponenty często są tymi, w których ich podsystemy muszą być zdolne do niezależnej awarii i nie powodować całkowitej awarii innych podsystemów lub całego komponentu. Wiele systemów jest napisanych w Erlang, aby osiągnąć te cele, aw niektórych przypadkach Erlang może być lepszym wyborem niż pisanie systemu w innym języku i używanie RPC tylko w celu uzyskania tych korzyści.

Podobnie jak większość problemów inżynierskich, nie ma jednego rozwiązania problemu komunikacji między procesami. Musisz spojrzeć na projektowany system i dokonać najlepszego wyboru dla swojego przypadku użycia.

Istnieje kilka głównych zalet REST, gdy produkty są skalowane w całym centrum danych, a Ty osiągasz wysoką dostępność i równoważenie obciążenia.

Pomyśl jednak o projekcie na mniejszą skalę. Potrzebujesz usługi internetowej, która będzie miała kilkaset żądań na godzinę? WCF zajmuje się wszystkimi kwestiami związanymi z transportem. Ma wygodny interfejs do wysyłania obiektów przez sieć i umożliwia konfigurację, szyfrowanie i certyfikację zerowego połączenia sieciowego za pomocą tylko pliku application.config.

Możesz mieć oba. Wtyczki takie jak RestRPC for Grails zawierają adnotacje, które będą przechwytywać wywołania twoich metod i obsługiwać je spokojnie, pozwalając ci mieć tyle, ile chcesz (co byłoby bardzo podobne do RPC).