Предоставить веб-сервису напрямую веб-клиентам или оставить промежуточный слой сценариев на стороне сервера?

Question

Я занимаюсь разработкой веб-сервиса REST (Java, Джерси). Люди, для которых я делаю это, хотят получить прямой доступ к веб-сервису через Javascript. Какой-то инстинкт подсказывает мне, что это не очень хорошая идея, но я не могу объяснить этот инстинкт. Мой естественный подход состоял бы в том, чтобы веб-сервис выполнял реальную логику и доступ к базе данных, но также имел некоторый (относительно тонкий) уровень сценариев на стороне сервера (например, в PHP). Клиенты будут общаться со слоем PHP, который, в свою очередь, будет общаться с веб-сервисом. (Веб-сервис будет довольно локальным по отношению к серверу apache / PHP и неявно доверяет вызовам из уровня сценариев. Уровень сценариев позаботится об управлении сессиями.) (Кстати, я не говорю о том, чтобы просто скрыть веб-сервис за Apache, который просто перенаправляет вызовы.)

Но поскольку у меня не хватает слов / аргументов для объяснения моего инстинкта, я задаюсь вопросом, прав ли мой инстинкт - обратите внимание, что, хотя я разрабатываю все виды программного обеспечения на всех видах языков и сред уже около 17 лет Это первый раз, когда я разрабатываю веб-сервис.

Итак, мой вопрос в основном: каково ваше мнение? Существуют ли стандартные настройки? Мой инстинкт совершенно не прав? Или частично? ; P

Большое спасибо,

Max

PS: Я мог бы добавить несколько бит информации о запланированном использовании всего приложения:

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

Answer 1

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

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

Для ваших требований:

все основные комбинации ОС / браузера могут ожидать от клиентов

Поскольку ваш веб-сервис будет доставлять только данные (например, JSON или XML), это не должно быть проблемой. Часть JavaScript просто должна позаботиться о том, чтобы выдавать правильные запросы.

потенциально будет очень высоким нагрузка / трафик

Если вы строго следуете архитектуре REST, вы можете использовать http-кэши. Но имейте в виду, что природа без гражданства всегда будет вызывать больше трафика.

логика веб-сервиса будет позже массово расширен для другого продукта который в основном является надмножеством функциональность текущего проекта

Хорошая особенность открытых веб-сервисов заключается в том, что вы можете свободно соединять их вместе.

существует значительная вероятность того, что в какой-то момент API должен быть выставлен который может быть использован третьей стороной разработчики - очевидно, с некоторыми Ограничения

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

в какой-то момент общественное мнение о продукт должен стать доступным через смартфоны

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

Answer 2

Во-первых, я просто расширяю то, что Дафф ответил выше. Я расширяю ответ Даффа с момента моего изучения или разработки и реализации RESTful WebServices, и, пожалуйста, обратите внимание, что я все еще учусь.

Когда я начал изучать RESTful WS с Java, Джерси (0.3 IIRC), у меня возникли аналогичные вопросы, и основной причиной этого было неправильное представление об общей архитектуре RESTful. Самой «серьезной» ошибкой, которую я совершил, было использование JAXB для XML и Джексона для JSON (де) сериализации непосредственно из / в bean-компоненты персистентности. Это полностью нарушает принцип REST и, следовательно, создает некоторые жизненно важные проблемы при создании высокопроизводительного, высокодоступного, масштабируемого веб-сервиса.

Моя ошибка заключалась в том, что, думая в терминах API a.k.a Service, когда мы думаем о RESTful WS, мы должны забыть «API» и думать: Ресурсы . Мы должны очень внимательно относиться к взаимосвязанным ресурсам. Мое понимание этого пришло только после прочтения this , я предлагаю его всем, кто хочет создать собственный веб-сервис. Мой вывод заключается в том, что Resource для RESTful WS / Architecture представляет собой API для нативного интерфейса или веб-службы SOAP. Поэтому я бы предложил тщательно спроектировать ваши ресурсы и понять, что ресурсы вашего WebService могут быть неограниченными.

Итак, вот как я пришел к выводу о реализации систем, предоставляющих «API» через RESTful WS. Я создаю API, который взаимодействует с бизнес-объектами, например, PersistentBook, который содержит либо идентификатор PersistentAuthor, либо сам объект. Вся бизнес-логика с учетом постоянных сущностей лежит на уровне реализации API.

Уровень веб-службы использует уровень API для выполнения своих операций над ресурсами. Уровень веб-службы использует постоянные сущности для генерации представлений bean-компонентов и наоборот, ключевой особенностью здесь будет представление PersistentBook, которое будет иметь URI для PersistentAuthor. Если я хочу использовать автоматическую (де) сериализацию, я создаю другой слой домена, например, Книга, Автор и т. Д.

Теперь, когда Дафф упоминал, что кэширование было бы неизбежным, мои контрольные точки для них -

• Поддержка заголовков ответов «Cache-Control», «Last-Modified», «ETag» и заголовков запросов «If-Modified-Since», «If-Match-None». Обратите внимание на мои недавние знания - используйте заголовок 'Vary' в случае различных представлений (согласование контента) на основе заголовка "Accept".
• Использование кэширования на стороне сервера, такого как Squid, Varnish, если клиенты не используют кэширование. Одна вещь, которую я узнал, наличие правильной поддержки заголовков ничего не значит, если клиенты их поддерживают, и фактически увеличивает стоимость с точки зрения вычислений и плохой пропускной способности;)
• Использование Content-Encoding.