Когда подходы RPC более подходящие, чем REST?

После просмотра этого выступления Стива Виноски о REST, Reuse и Serendipity , мне стало интересно, есть ли бизнес-примеры в новых проектах (XML-) RPC-ish, которые REST не мог бы решить лучше.

Несколько проблем RPC он упоминает:

• Сосредоточиться на языке (приспособить распределенную систему к языку, а не наоборот)
• «Сделайте так, чтобы это выглядело локально» (и справляйтесь с ошибками и задержками как исключениями, а не правилом)
• предполагается, что он не зависит от языка, но все еще содержит «вызовы функций» в разных языках в качестве основного компонента
• IDL шаблон
• Иллюзия безопасности типа
• и еще несколько ...

Немного драматизирую некоторые результаты Google Instant для RPC против REST:

В общем, RPC предлагает гораздо больше языковой интеграции, чем REST. Как вы упомянули, это связано с рядом проблем с точки зрения масштаба, обработки ошибок, безопасности типов и т. Д., Особенно когда в одной распределенной системе задействованы несколько хостов, на которых выполняется код, написанный на нескольких языках. Однако после написания бизнес-систем, использующих RPC, REST и даже обе одновременно, я обнаружил, что в некоторых случаях есть веские причины выбирать RPC вместо REST.

Вот случаи, когда я нашел RPC лучше подходящим:

• Тесная связь. (Распределенные) компоненты системы предназначены для совместной работы, и изменение одного из них, вероятно, повлияет на все остальные. Вряд ли компоненты должны быть адаптированы для связи с другими системами в будущем.
• Надежное общение. Компоненты будут взаимодействовать друг с другом либо полностью на одном хосте, либо в сети, в которой маловероятно возникновение проблем с задержкой, потерей пакетов и т. Д. (Однако, это все еще означает, что вам необходимо разработать систему для обработки этих случаев).
• Единый язык. Все (или в основном все) компоненты будут написаны на одном языке. Вряд ли в будущем будут добавлены дополнительные компоненты, написанные на другом языке.

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

Вышеупомянутые три элемента часто встречаются, когда вы хотите построить один компонент более крупной системы. По моему опыту, эти компоненты часто являются теми, где их подсистемы должны иметь возможность выходить из строя независимо и не вызывать полного отказа других подсистем или всего компонента. Многие системы написаны на Erlang для достижения этих целей, и в некоторых случаях Erlang может быть лучшим выбором, чем написание системы на другом языке и использование RPC просто для получения этих преимуществ.

Как и большинство инженерных проблем, не существует единого решения проблемы межпроцессного взаимодействия. Вам нужно посмотреть на систему, которую вы разрабатываете, и сделать лучший выбор для вашего варианта использования.

Существует несколько основных преимуществ REST, когда продукты масштабируются в центре обработки данных, и вы выполняете высокую доступность и балансировку нагрузки.

Однако подумайте о меньшем проекте. Нужен веб-сервис, который будет иметь несколько сотен запросов в час? WCF занимается всеми транспортными вопросами. Имеет удобный интерфейс для отправки объектов по сети и позволяет конфигурировать, шифровать и сертифицировать сетевое соединение с нулевым программированием, используя только файл application.config.

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