REST був розроблений для Інтернету, а веб - для REST. Двоє просто підходять разом. Докторська дисертація Роя Філдінга 2000 р. " Архітектурні стилі та дизайн мережевих програмних архітектур" визначила і ввела термін REST , і між Інтернетом та REST існує значна взаємозв'язок: Рой Філдінг працював над HTTP / 1.1, головним автором якого є, і він використав те, що там дізнався, щоб описати REST у своїй дисертації.
Отже, найпростіша причина, по якій Інтернет та REST так добре поєднуються, полягає в тому, що визначення REST було витягнуто з того, як працює Інтернет, а веб - це реалізація REST.
Ось чому REST добре підходить для веб-служб та веб-додатків: адже ви просто робите ті самі речі, які вже було доведено, що вони працюють у "людській" павутині, і застосовуєте їх до "машинної" мережі.
Велика проблема з RPC ( в залежності від точної реалізації) лежить в основному в Хибні уявлення заважають розподілених обчислень , які більш детально описані в цьому документі по Арнон Ротем-Гал-Оз :
- Мережа надійна
- Затримка дорівнює нулю
- Пропускна здатність нескінченна
- Мережа захищена
- Топологія не змінюється
- Є один адміністратор
- Вартість транспорту дорівнює нулю
- Мережа однорідна
Це все припущення, які зазвичай роблять новачки, коли вони починають створювати розподілені системи. Звичайно, всі вони помилкові. І їх потрібно враховувати при створенні розподілених систем.
Проблема багатьох реалізацій RPC полягає в тому, що вони намагаються зробити віддалені дзвінки схожими на локальні дзвінки. Але вони нічим не схожі:
- місцевий дзвінок ніколи не виходить з ладу; підпрограми , які ви назвали , може потерпіти невдачу, але виклик сам ніколи не робить - віддалений виклик може заблукати в мережі
- місцевий дзвінок миттєвий; підпрограма , що ви назвали , може працювати в протягом тривалого часу (або навіть назавжди , якщо він застряє в нескінченному циклі), але виклик сам по собі не має взагалі ніякого часу (ну, кілька інструкцій процесора в кращому випадку , менше , якщо виклик вбудований, але це дуже швидко) - віддалений дзвінок може застрягти в мережі на тривалий час
- якщо підпрограма повертається нормально, результат завжди повертається - при віддаленому дзвінку результат може загубитися в мережі
- віддача миттєва - віддалені результати можуть довго подорожувати по мережі
- якщо я зателефоную підпрограмі один раз, вона запуститься рівно один раз - віддалений виклик може загубитися в мережі або дублюватися, так що віддалена програма може працювати між 0 і будь-якою кількістю разів
- Я повертаю рівно один результат - віддалений результат може втрачатися або дублюватися, тож ви можете отримати результат 0 і більше разів
- якщо я дзвоню в підпрограму двічі, я отримую два результати, і я отримую результат першого дзвінка перед результатом другого виклику - ви, напевно, можете це здогадатися вже зараз: з RPC ви можете отримати жодних результатів або лише перший , або тільки другий, або другий перед першим, або перший може бути загублений, і ви отримуєте другий двічі, або навпаки, і так далі ...
- якщо я дзвоню
aі потім b, я отримую результат, aа потім результат b - це просто більш загальна версія попереднього пункту, з RPC, ви можете отримати будь-який з двох відповідей 0 або більше разів у будь-якому порядку
Ви будете мати справу з усіма вище для віддаленого виклику. Але якщо ваша система робить віддалені дзвінки, які не відрізняються від місцевих дзвінків, ви не можете , оскільки ви не знаєте, які з них є віддаленими дзвінками. Рамка може спробувати впоратися з усім цим для вас, але проблема полягає в тому, що рамка не знає стільки про вашу систему, як ви. Невідомо, чи є дзвінки, де насправді не має значення, якщо хтось загубиться. Отже, рамки повинні бути дуже оборонними, і це дорого з точки зору затримки та пропускної здатності.
Тим більше, що рамка насправді не може захистити вас. CAP теорема говорить про те , що розподілена система не може бути послідовною, в наявності, і секції Стійкі в той же час; точніше, це говорить про те, що як тільки відбувається Розділ, система не може продовжувати бути послідовною і доступною, вона повинна вибрати один (всупереч поширеній думці, теорема не говорить про те, що у вас не може бути всіх трьох, коли система працює як правило, ви можете мати усі три, але як тільки у вас є розділ, ви повинні вибрати один з двох інших). PACELC теорема розширює CAP теорему, показавши , що навіть тоді , коли система працює, ви повинні знайти компроміс латентності по порівнянні з консистенцією.
Це важливі компроміси, від яких рамки практично не можуть захистити вас, оскільки вони є доменними і важливими для основної конструкції.
Порівняйте це з підходом , як Erlang, який робить роботу: в Erlang, все повідомлення посилів розглядаються як віддалені, навіть якщо вони є локальними. Це означає, що ви завжди готові вирішити всі вищезазначені проблеми (та багато іншого). Для локальних процесів вони, однак, створюють трохи накладні витрати. Для того, щоб допомогти у цьому, існує велика кількість інструментів, рамок, бібліотек, шаблонів та ідіом для вирішення проблем та контролю над помилками.
Ви не описували, як працює ваша рамка RPC, зокрема, і якою мовою чи бібліотеками ви користуєтесь, але у мене є велика підозра на те, що вона належить до колишнього типу "робите вигляд, що мережа не існує". Ті просто не працюють. Це нормально , щоб усунути розходження між локальними і віддаленими викликами шляхом обробки все як віддалений виклик. Це робиться навпаки занадто багато рефератів: мережа є частиною вашої системи, якщо ви її абстрагуєте, ви абстрагуєте щось, що вам потрібно знати.
Тепер, чи потрібно спеціально використовувати REST чи ні, це зовсім інше питання. Як я пояснював вище, веб був розроблений для REST, а REST був розроблений для Інтернету, тому вони мають сенс разом, але ви можете використовувати інші архітектурні стилі, якщо хочете. Але принаймні частина вашого питання стосувалася питання "чому б не RPC", і я виклав причини, описані вище, точніше пояснив, чому тип RPC, який я підозрюю, ви використовуєте, може створити вам проблеми.