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

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

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

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

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

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

Ответ 1

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

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

Использование SOAP обычно лучше, чем простой старый xml по следующим причинам:

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

SOAP

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

<сильного > REST

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

MySite.com/Add/5/3

или

MySite.com/GetStockSymbol/Facebook

или

MySite.com/GetWeather/Paris/France

Ответ 5

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

В отрасли есть два основных варианта использования WEB:

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

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

Ответ 6

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

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

Ответ 7

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

Подход к веб-службам хорош, если

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

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

с. более одного потребителя для такого же обслуживания - как банки, потребляющие данные от Агентства кредитных отчетов

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

Ответ 8

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

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

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

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

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

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

Ответ 9

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

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

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

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