Коли підходи RPC-ish більш доцільні, ніж REST?

Подивившись цю розмову на REST, повторному використанні та Serendipity Стівом Виноскі, мені цікаво, чи є бізнес-випадки в проектах Greenfield для (XML-) RPC-ish налаштувань, які REST не вдалося вирішити кращим чином.

Кілька проблем RPC, про які він згадує:

• Зосередьтеся на мові (підходите розподілену систему до мови, а не навпаки)
• "Зробіть так, щоб він виглядав локальним" (і впорайтеся з невдачею та затримкою як винятки, а не як правило)
• призначений бути незалежним від мови, але все ще має "функціональні дзвінки" на різних мовах як основний інгредієнт
• Плити котла IDL
• Ілюзія безпеки типу
• і ще кілька ...

Для того, щоб трохи його драматизувати, деякі результати миттєвого пошуку Google для RPC проти REST:

Загалом, RPC пропонує набагато більше мовної інтеграції, ніж REST. Як ви вже згадували, це виникає з низкою проблем з точки зору масштабу, керування помилками, безпеки типу тощо, особливо коли в одній розподіленій системі задіяно кілька хостів, що працюють з кодом, написаним на декількох мовах. Однак після написання бізнес-систем, які використовують RPC, REST і навіть обидва одночасно, я виявив, що є певні вагомі причини вибрати RPC над REST у певних випадках.

Ось випадки, коли я визнав RPC найкращим чином:

• Щільна муфта. (Розподілені) компоненти системи розроблені для спільної роботи, а зміна одного, ймовірно, вплине на всіх інших. Навряд чи компоненти в майбутньому доведеться адаптувати для спілкування з іншими системами.
• Надійне спілкування. Компоненти будуть спілкуватися один з одним або повністю на одному хості або в мережі, що навряд чи матиме проблеми із затримкою, втратою пакетів тощо. (Це все ж означає, що вам потрібно створити вашу систему для обробки цих випадків.)
• Єдина мова. Всі (або в основному всі) компоненти будуть написані однією мовою. Навряд чи в майбутньому будуть додані додаткові компоненти, написані іншою мовою.

Щодо точки зору IDL, в системі REST вам також потрібно написати код, який перетворює дані в REST-запити та відповіді у будь-яке внутрішнє представлення даних, яке ви використовуєте. Джерела IDL (з хорошими коментарями) також можуть слугувати документацією інтерфейсу, який повинен бути записаний і підтримуватися окремо для REST API.

Вищевказані три елементи часто трапляються, коли ви хочете створити один компонент більшої системи. На мій досвід, ці компоненти часто є тими, де їх підсистеми повинні бути здатні самостійно виходити з ладу і не викликати повного виходу з ладу інших підсистем або всього компонента. Для досягнення цих цілей написано багато систем на Ерланг, і в деяких випадках Ерланг може бути кращим вибором, ніж написання системи на іншій мові та використання RPC просто для отримання цих переваг.

Як і більшість інженерних проблем, немає єдиного рішення проблеми міжпроцесорної комунікації. Вам потрібно переглянути систему, яку ви проектуєте, і зробити найкращий вибір для вашої справи використання.

Є деякі основні переваги REST, коли продукти збільшуються через центр обробки даних, і ви робите високу доступність та балансування завантаження.

Однак подумайте про менший масштабний проект. Потрібна веб-служба, яка матиме кілька сотень запитів на годину? WCF займається всіма транспортними питаннями. Має зручний інтерфейс для передачі об’єктів по всій мережі і дозволяє налаштувати, зашифрувати та сертифікувати мережеве з'єднання з нульовим програмуванням, використовуючи лише файл application.config.

Ви насправді можете мати і те, і інше. Плагіни, такі як RestRPC for Grails, надають примітки, які перехоплюватимуть виклики до ваших методів та спокійно оброблятимуть їх, дозволяючи вам мати стільки, скільки вам потрібно (що було б дуже схожим на RPC).