REST для локальных интерфейсов?

Question

Я создаю небольшой инструмент управления пользователями, который должен использоваться с веб-интерфейсом (возможно, с Wicket). Некоторые сервисы, предоставляемые этим инструментом, должны быть REST-полными, и теперь мне интересно, должен ли REST быть единственным внешним интерфейсом (имея в виду CouchDB с его интерфейсом REST). Часть приложения с графическим интерфейсом затем будет выполнять вызовы REST вместо вызовов локальных методов. Оба будут развернуты на одном сервере.

Преимущества интерфейса только для REST: слабая связь, унифицированный интерфейс.

Недостатки: HTTP-накладные расходы, объекты должны быть преобразованы в и из формата передачи (например, JSON), сложнее в реализации.

Эти недостатки позволяют мне думать, что я должен использовать REST только для реальных удаленных интерфейсов. Я что-то пропустил?

Answer 1

Любой вид удаленного общения обходится дорого. Вы должны убедиться, что вы получаете то, что стоит того. Очень часто огромное количество инфраструктуры, доступной для поддержки RESTful HTTP - браузер, серверы, посредники, такие как прокси и кеши, инструменты, такие как curl или wget, - а также тот факт, что информация в вашем бэкэнде становится связываемой, не говоря уже о Хотя стандартные методы, коды ответов, методы кэширования и т. д. того стоят. Иногда это не так - почти невозможно сказать без подробностей вашего заявления. И даже в этом случае субъективное проектное решение остается вне зависимости от того, перевешивают ли все преимущества слабого сцепления стоимость.

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

Answer 2

Ваш оригинальный интерфейс также может хорошо работать как интерфейс REST.

Есть две большие проблемы, которые вам нужно преодолеть.

1) Во многих графических интерфейсах есть компонент рабочего процесса, построенный на основе требований к интерфейсу. Например, большая форма представлена ​​в виде нескольких страниц. Это в первую очередь сделано для пользователей-людей, так как большинство компьютеров на самом деле не заботятся.

2) Современные браузеры не поддерживают все глаголы HTTP (PUT, DELETE и т. Д.).

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

Второй может быть обработан с использованием простого прокси. В частности, если вы хотите выполнить, скажем, DELETE, вы можете передать глагол своему прокси-серверу, который обрабатывает POST и глагол = DELETE так же, как и DELETE. Просто убедитесь, что ваш сервер поддерживает оба одинаково. Или вы можете использовать Ajax на своих страницах, чтобы совершать правильные звонки.

Хотя интерфейс, представленный через графический интерфейс пользователя, может не быть «REST» на педантичном уровне, базовая система работает, по крайней мере, на уровне протокола, поскольку все это соответствует основным ограничениям архитектуры.

Еще одна вещь, которую вы можете сделать, это принять формы, закодированные URL, в качестве входных данных, но вернуть XML в качестве выходных данных. Ключевым моментом здесь является то, что вы можете отправить вместе с XML таблицу стилей XSLT. Таким образом, когда он отображается в браузере, вы получаете полный код HTML с графикой, кнопками и всем остальным. Если вы вызываете его через универсальный клиент, вы получаете чистый XML без всяких «излишеств».

Вы можете встретиться на полпути, используя XHTML и микроформаты. Полезная нагрузка не будет значительно больше полезной нагрузки, связанной с чистым XML, но все же это нормально, каждый день XHTML с удовольствием от CSS для рендеринга в браузерах.

Answer 3

Мое мнение (это ключ) заключается в том, что вы должны придерживаться только REST. Зачем? потому что вы сказали, что это маленький инструмент управления пользователями. Это означает, что это маленький и легкий инструмент. зачем тратить время на создание нескольких интерфейсов, если не становится ясно, что они вам нужны?

тем не менее, я не очень понимаю, что вы пытаетесь сделать. GUI-оболочка к тому, что по сути является couchdb? или есть другие компоненты? мое первоначальное мнение, вероятно, придерживается ..