Веб-служба против веб-приложения

Question

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

Я создаю приложение, которое будет использоваться другими приложениями (мобильными/сетевыми) для извлечения данных. Теперь у меня есть 2 варианта:

1. Создайте приложение как простое веб-приложение.
2. Создайте веб-сервис.

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

Мой вопрос в том, что это может быть достигнуто простым веб-приемом, принимающим запрос в формате XML и ответом на ответ XML. Чувство кишки заключается в том, что веб-сервис станет лучшим способом для такого рода услуг, где мы не уверены, кто все это будет использовать. Но существуют ли какие-либо конкретные преимущества использования веб-службы через простое веб-приложение?

Answer 1

На низкоуровневых веб-приложениях и веб-сервисах это одно и то же. Они оба работают над http (s). SOAP - это всего лишь четко определенная версия XML. REST - это просто HTTP. Если бы вы захотели, вы могли бы сделать веб-приложение похожим на веб-службы и наоборот.

Основное отличие - это внутренние варианты развития, основанные на используемой платформе. Если, например, вы используете Visual Studio, то добавление Сервисного приложения WCF даст вам проект, который по умолчанию предназначен для WCF. Но выбор любого другого типа приложения не остановит вас от добавления веб-служб.

Использование SOAP, как правило, это лучший вариант, чем простой старый XML по этим причинам:

• Ваши пользователи будут ожидать его, и, вероятно, знают, как читать его уже.

• Среда разработки ваших пользователей, скорее всего, знает все о SOAP и сможет интерпретировать ее из коробки. (Если вы предоставите WSDL-файл, многие пользователи смогут использовать скрипт для генерации ваших классов за считанные секунды.)

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

Answer 2

Если вашему приложению не нужен пользовательский интерфейс, то сделайте его веб-сервисом. Если ему нужен пользовательский интерфейс, используйте веб-приложение.

Answer 3

Мой вопрос заключается в том, что это может быть достигнуто простым веб-приемом, принимающим запрос в формате XML и ответом на ответ XML.

Это веб-сервис. Я думаю, что это вопрос терминологии.У вас нет способа решить эту проблему, кроме как использовать веб-сервис, независимо от того, является он спокойным или основанным на SOAP, зависит от вас, но если вы передаете данные клиентам в формате XML в ответ на запросы XML, это веб-служба.

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

SOAP

Если сервис имеет множество функций, чем пользователей Java и/или визуальной студии предпочли бы импортировать файл WSDL и использовать службу в качестве объекта со всеми XML разборе сделал для них , поэтому SOAP будет ответом.

ОСТАЛЬНЫХ

Если у вас есть только несколько функций, с очень простыми входными параметрами и данными ответа, то SOAP может быть излишнее.

MySite.com/Add/5/3 

или

MySite.com/GetStockSymbol/Facebook 

или

MySite.com/GetWeather/Paris/France 

Answer 4

Если мы думаем, что терминология, которую я думаю, что главный вопрос здесь.

Веб-сервис относится к программному обеспечению, которое обслуживает данные в любом формате (XML/JSON и т. Д.) Через какой-либо веб-интерфейс. Этот интерфейс можно назвать API (Application Programming Interface). REST и SOAP - это способы разработки API.

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

Другими словами, веб-служба является «сервером», а приложение является «клиентом». Обычно сервер обслуживает машины и клиенты, обслуживающие пользователя.

Таким образом, в любом случае вы решили создать свою систему, я бы назвал часть, которая обслуживает данные как «веб-сервис», и часть, которая использует данные как «приложение» (или «веб-приложение», если таковое имеется).

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

Answer 5

Я знаю его слишком поздно, чтобы повторить, но все-таки я хочу

Web Services подход хорош, если

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

b. подходит для распределенных приложений

c. более одного потребителя за тот же сервис - как Банки, потребляющие данные от Кредитного бюро

d. потребители хотят получать данные в разных форматах - как один потребитель (клиент) хочет в формате XML, другой - в JASON ..и т.д.

Answer 6

Я думаю, что это может помочь вам в решении вашей путаницы

Есть два основных варианта использования веб в отрасли

1. Бизнес потребителя (B2C): Всякий раз, когда есть потребитель непосредственно взаимодействующей с бизнесом для его нужд мы всегда используем веб-приложение , чтобы обеспечить связь между двумя сторонами.
2. Бизнес для бизнеса (B2B): это означает, что одна часть бизнеса нуждается в некоторых входах/услугах из другой части бизнеса. Всегда используется веб-служба для удовлетворения бизнес-требований. Обычно потребитель никогда не взаимодействует с веб-службами напрямую, мы взаимодействуем с веб-приложением, а веб-приложение взаимодействует с веб-службами с веб-сервисами для информации/данных или обработки.

Взятые из http://coder2design.com/java-interview-questions/

Answer 7

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

Задача, с которой я столкнулся, когда задавала этот вопрос, заключалась в том, что я запутался между условиями применения и сервисом (обратите внимание, что веб-сайт является общим элементом в веб-приложении и веб-сервисе). Как следует из названия, приложение является приложением само по себе, тогда как служба предназначена для обслуживания других. Служба, вероятно, не имеет никакого значения, если кто-то ее не использует. Он может обслуживать одно или несколько приложений или служб.

Теперь, если я смотрю на мой вопрос

Я создаю приложение, которое будет использоваться другими приложениями (мобильный/веб) для выборки данных. Теперь у меня есть 2 варианта: 1. создать мое приложение как простое веб-приложение. 2. Создать веб-сервис.

Я хотел бы сказать себе, что «Чувак! Если есть объект, который принимает запрос и возвращает данные, вы говорите об услуге». Потому что я не беспокоюсь о том, что произойдет с этими данными? Кто его будет использовать? Как это будет отображаться?

Я беру запрос и возвращаю данные. Теперь, как я это делаю, это часть реализации. Я мог бы использовать SOAP или REST. Я могу использовать Джерси или Spring MVC/REST или может быть простым сервлетом, который принимает запрос и возвращает данные в JSON или XML или String или в любом другом требуемом формате.

Answer 8

Веб-службы не всегда имеют пользовательский интерфейс. Обычно они используют API, используя JSON, также могут быть SOA-типами с использованием SOAP и XML в основном, могут также быть сокетами, а также серверами и другими микро-веб-сервисами и т. Д.

Веб-приложения могут быть объединены многими способами. Существует несколько способов создания приложения путем организации нескольких веб-сервисов и отдельного gui для управления ими, которые связаны с этими службами.Другой способ, который не использует сервисы, - это процедурно внедрить код в ваше приложение интерфейса интерфейса или, что еще лучше, сделать объектно-ориентированное приложение, которое позже будет иметь свои собственные сервисы, разделенные в модели, и доступ к контроллеру имеет свое собственное представление как графический интерфейс, который обращается к службам на задней панели или даже более сложные приложения, которые передают услуги A2B, B2B и B2C из некоторого графического интерфейса.

Услуги не всегда имеют графический интерфейс, они могут иметь CRUD для хранения данных, но как только вы начнете использовать эти типы функций, он станет самостоятельным приложением. Услуги применяются к чему-то большему, чем они сами. это приложение создает ваше приложение. Он должен иметь цель. Обычно для завершения вашего приложения требуется несколько слепых сервисов, и есть какой-то интерфейс.

Если вы только слепо отослали запрос uri к вашему сервису, и он слепо отправит обратно json, это сервис. Что слепо посылает это? Если вы, то не приложение. Если какой-то crud, а затем становится его приложением, crud является графическим интерфейсом для доступа к сервисам и в целом его системой управления данными. Теперь, если вы разместите слой на передней панели, чтобы продемонстрировать эти данные на веб-сайте, теперь у вас есть продукт для отображения этих данных, продукта для его управления и данных, которые являются реальным продуктом и доступного через веб-службу , теперь это полная заявка. Ваши усилия по созданию этого станут вашим приложением.

Answer 9

От RESTful Web Services Леонард Ричардсон и Сэм Руби, ISBN: 978-0-596-52926-0:

веб-сервисы действительно очень похожи на веб-приложений, но создание ресурсов является одним из мест, где они отличаются. Основное отличие здесь в том, что HTML-формы в настоящее время поддерживают только GET и POST. Это означает, что веб-приложения должны использовать перегруженный POST для передачи любой небезопасной операции.