Подход REST означает просто, что приложение A будет выполнять запросы приложения B (и, возможно, наоборот), используя протокол HTTP. Отправка данных может быть в любом формате, который вам нравится, хотя JSON по умолчанию сегодня (и XML был по умолчанию вчера, и даже ... SOAP - gaq!).
В наши дни подавляющее большинство внешних API реализовано таким образом - Amazon, Google Maps, Yelp и т. Д. И т. Д. И т. Д. И т. Д. Почему? Потому что протокол HTTP (или HTTPS) хорошо понят и широко распространен. Никакой специальной настройки не требуется, и тот же протокол, который предоставляет приложение обычным людям в веб-браузерах, работает для других приложений. Rails делает это блестяще легко (если вы плывете по течению).
RMI в Java - это особый протокол (как и HTTP). Преимущество состоит в том, что объекты, определенные в A, доступны как экземпляры в B (после большой работы в обоих). Это действительно имеет смысл, когда у вас есть набор приложений, спроектированных заранее для совместной работы, основное требование которых должно быть распределено по местоположениям, серверам и т. Д. RMI создает жесткую связь между приложениями - изменение одного обычно требует изменения в другом. Это подходит для некоторых видов приложений.
Но если у вас есть, например, два отдела в компании, которые общаются друг с другом, но не хотят быть "связанными в беде", интерфейс REST обеспечивает большую гибкость.
На ваш второй вопрос («как тяжело») очень сложно ответить. Компания, в которой я работал в 2001 году, имела сотни серверов, каждый из которых выполнял экземпляр «рабочего» процесса - все они были предназначены для того, чтобы ставить свои результаты в очередь в процесс «контроллера», который обрабатывал бы выходные данные и пересылал их на другие установленные серверы, предназначенные для обрабатывать и управлять данными. В 2001 году это была правильная архитектура, потому что она была полностью разработана для совместной работы - постоянные сокетные соединения в одной подсети нашей интрасети, работающие в комнате, полной серверов. Теперь, в 2012 году, эта комната, полная серверов, заменяется несколькими мощными процессорами, работающими на 64-битных ОС и использующими огромные объемы памяти - это совершенно новый мир. Удвоение производительности в 2001 году может сэкономить миллионы долларов на оборудовании, операционной поддержке, пространстве и так далее. В 2012 году самое дорогое - хорошие разработчики! Так что «тяжелый» действительно не имеет никакого отношения ко всем операциям, кроме самых интенсивных в наши дни. HTTP-запрос легкий и простой.
Последний вопрос: понятный двоичный формат. Конечно, если нужно. В конце концов, любой двоичный формат, который передается по проводам между двумя серверами, должен быть сериализован и десериализован как поток, и это работа, как для программистов, так и для машин. JSON - это текстовый формат, но он изначально понят в JavaScript (нотация объектов JavaScript) и имеет явное преимущество, заключающееся в удобочитаемости человеком. Учитывая, что большинство серверов настроены на автоматическое сжатие вывода, независимо от того, является ли что-то текстовым или двоичным, оно становится менее актуальным, по крайней мере, в отношении ввода-вывода и полезной нагрузки. Конечно, вы можете придумать любой взаимно понятный формат и отправить его по HTTP, но, опять же, это то, что имело значение десятилетие назад, и сегодня, как правило, не стоит рассматривать вопрос. Процессоры становятся все быстрее и быстрее, а память - дешевле (и больше) - поэтому (как всегда) ввод-вывод (сетевой или дисковый) является типичным узким местом в современных приложениях.
Если бы мне пришлось изменить дизайн приложения, о котором я упоминал в 2001 году, где сотни (сегодняшних) серверов должны были взаимодействовать с (многими) одноранговыми серверами, специально предназначенными для взаимодействия, я мог бы позаботиться о том, чтобы процесс сериализации / десериализации было максимально легким (но только , если оказалось узким местом). Для меня привязанность к какой-либо конкретной платформе или языку не является началом - компьютерный мир движется быстро.
Но сегодня практически во всех реалистичных бизнес-приложениях простота, простота и простота имеют как настоящие, так и будущие преимущества, которые делают необходимость одержимо беспокоиться о производительности в прошлом.
Надеюсь, это поможет: -)