Вы бы спроектировали управляющий API следующего марсохода следующего поколения как RESTful вместо RPC?

Question

Простите, если это граничит с вопросом "обсуждения", но я бы действительно оцените ответ да / нет, с соответствующим объяснением.

Предположим, вам нужно спроектировать и внедрить управляющий API для робота, скажем, следующий Марс Ровер поколения. Вы разрабатываете этот API в соответствии с RESTful? принципы, или вы используете классический RPC, такой как XMLRPC?

Я спрашиваю об этом, потому что я должен сделать нечто подобное, хотя «робот» - это набор виртуальных машин. Один довольно убедительный инженер, известный адвокат REST, убеждает меня сделать API RESTful. Я никогда не использовал принципы REST, и я изо всех сил пытаюсь понять, как они подходят для разработки низкоуровневых межпроцессных API. REST, кажется, проникнут темой взаимодействия с изменяемым хранилищем данных, обычно за много прыжков. То, что я пытаюсь сделать, больше похоже на тесное управление роботом. Я могу видеть, как можно утверждать, что робот - это всего лишь хранилище данных - «PUT, левый поворот», «PUT, проезд 100 метров», «GET наружная температура». Но это, кажется, довольно надуманная модель. Я, конечно, не получу никакой выгоды от кеширования или прокси-сервера («Привет, JPL? Это Akamai co-lo в Канберре. Мы сейчас переходим на Ровер, хорошо?»)

Итак, полезна ли здесь архитектура RESTful? Это все еще превосходит RPC даже когда взаимодействие так узко сфокусировано?

Answer 1

Я думаю, что REST будет иметь больше смысла, чем традиционный RPC. Даже модель времени выполнения Micorosft Robotics Studio использует REST.

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

REST делает акцент на гарантировании побочных эффектов определенных методов, а также облегчает кэширование, которые могут быть полезны для чего-то вроде управления и мониторинга удаленного робота. И только потому, что вы можете использовать REST, не обязательно должен быть протоколом HTTP.

Однако безопасный метод IDEMPOTENT, такой как GET, хорош для отслеживания состояния робота и опроса данных его датчика. Вы можете использовать что-то вроде заголовка Last-Modified для получения кэшированных данных датчика, которые меняются не часто (например, уровень влажности или уровень освещенности).

Для больших расстояний вы можете использовать релейные прокси для кеширования.

Для команд, которые перемещают робота, будет использоваться что-то вроде POST, где каждое такое сообщение изменит робота (например, повернуть направо). Может быть возвращен код состояния, указывающий, была ли команда немедленно выполнена или поставлена ​​в очередь для обработки.

Абсолютное состояние любых ресурсов можно установить, используя что-то вроде PUT, когда несколько сообщений не изменят ничего, кроме одного сообщения (например, указание на северный полюс или приглушенный передний свет с яркостью 10%). Это обеспечивает надежный обмен сообщениями в случае вероятности потери сообщений в пути.

Новый ресурс также может быть создан с помощью POST-подобной операции, например, с помощью процедуры сбора данных и набора параметров. Запрос POST может отправить обратно CREATED результат с URI для нового ресурса, который можно использовать для УДАЛЕНИЯ, когда он больше не нужен.

Группа роботов может также разговаривать друг с другом, используя один и тот же протокол на основе REST, и может пользоваться теми же преимуществами.

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

Answer 2

Принципы REST гарантируют, что ваше приложение хорошо масштабируется и хорошо взаимодействует с посредниками через Интернет (прокси, кэширование и т. Д.) Если ваша сеть «виртуальной машины» является крупномасштабной, тогда может быть полезна архитектура RESTful. Если вы строите небольшую сеть, REST не будет таким привлекательным.