Веб-интерфейс для спокойного интерфейса, хорошая идея?

Question

Я работаю над экспериментальным веб-сайтом (который доступен через веб-браузер), который будет работать в качестве внешнего интерфейса для успокоительного интерфейса (подсистемы). Веб-сайт будет служить интерфейсом между пользователем и интерфейсом restful, поскольку он будет отправлять http-запросы к интерфейсу restful практически для всех операций с базой данных. Аутентификация, вероятно, будет выполняться с использованием openid, а авторизация для операций с базой данных будет осуществляться через oAuth.

Просто из любопытства, это выполнимое решение, или мне следует разработать две системы, которые обращаются к базе данных параллельно (т. Е. У веб-сайта есть своя собственная логика доступа к данным, а у остального интерфейса есть другая логика доступа к данным)? И каковы плюсы / минусы, если я настаиваю на том, чтобы делать это таким образом (это всего лишь экспериментальный проект для меня, чтобы узнать такие вещи, как OpenID и oAuth в реальной жизни в любом случае), кроме того, будет больше запросов к базе данных и запросов http, генерируемых для каждая транзакция?

Answer 1

Ваша концепция звучит вполне осуществимо. Я бы сказал, что вы получите довольно неплохие победы от такого подхода. Для начала вы получите большую степень повторного использования кода, так как вы сможете разместить другие интерфейсы поверх сервиса RESTful. Кроме того, вы сможете сравнительно легко протестировать эту архитектуру. Наконец, вы сможете предоставить сторонним разработчикам доступ к тому же API, который вы используете (возможно, с некоторыми ограничениями), что станет огромным выигрышем в привлечении клиентов и разработчиков на вашу платформу.

С другой стороны, в зависимости от того, как вы структурируете свой сервер, вы можете столкнуться со стандартной проблемой гранулярности. Слишком большая детализация, и вы в конечном итоге создадите множество соединений для очень небольших объемов данных. Слишком мало, и вы получите больше данных, чем вам нужно в некоторых случаях. Что касается безопасности, вы должны иметь возможность заблокировать серверную часть, чтобы запросы могли выполняться только при определенных условиях: запросы содержат токен авторизации, ключ API и т. Д.

Answer 2

woow! Вопрос с 2009 года! И смешно читать ответы. Многие люди, похоже, не согласны с подходом веб-сервисов и интерфейсом JS, который сегодня стал своего рода стандартом, известным как одностраничные приложения

Answer 3

с современной библиотекой javascript ваш подход довольно прост.

ExtJS теперь всегда имел поддержку Ajax, но теперь он может делать это через интерфейс REST.

Итак, компоненты вашего пользовательского интерфейса ExtJS получают URL. Они заполняются через GET для URL и сохраняют обновления через POST для URL.

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

Удачи, Ian

Answer 4

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

В противном случае, используйте отличный MVC-фреймворк (asp.net MVC, rails, cakephp). В итоге вы получите тот же базовый результат, но вы будете «сильнее» набраны в базу данных.

Answer 5

Итак, чтобы уточнить, вы хотите, чтобы ваш веб-интерфейс вызывал вашу веб-службу, которая, в свою очередь, обращается к базе данных?

Это именно тот путь, который я выбрал для недавнего проекта, и я думаю, что это было ошибкой, потому что в итоге вы создали много дополнительной работы. И вот почему:

Когда вы кодируете свой веб-сервис, вы создадите библиотеку для переноса вызовов базы данных, что типично. Там нет проблем.

Но затем, когда вы закодируете свой веб-интерфейс, вы в конечном итоге создадите еще одну библиотеку для переноса вызовов в интерфейс REST ... потому что в противном случае выполнение громких HTTP-вызовов станет громоздким. *

Итак, вы, по сути, создали 2 библиотеки доступа к данным, одну для переноса БД, а другую для переноса вызовов веб-службы. Это в основном удваивает объем работы, которую вы выполняете, потому что для каждой операции над ресурсом вы будете реализовывать обе библиотеки. Это очень быстро утомляет.

Более простая альтернатива - создать единую библиотеку, которая, как и прежде, обертывает доступ к базе данных, а затем использовать эту библиотеку из ОБА веб-интерфейса и веб-службы.

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

Answer 6

Я думаю, что общий подход, который вы обрисовали, вполне осуществим - основной плюс - гибкость, основной недостаток - то, что он не защитит невежественных пользователей от их собственных ((исключенных удаленных)) злоупотреблений. Поскольку большинство пользователей, вероятно, не имеют понятия, это неосуществимо для массового потребления ... но для действительно активных пользователей это нормально! -)