Soap что это: Различия REST и SOAP / Хабр

Разное 

Содержание

Различия REST и SOAP / Хабр

Эта вторая статья в серии постов о разработке REST API:

В этой статье рассматриваются некоторые аспекты основных различий между REST и SOAP.

Упс… на самом деле, сравнивать их немного похоже на сравнение яблок с апельсинами, поскольку SOAP — это формат протокола, основанный на XML, тогда как REST — это архитектурный подход.



Вы изучите


  • Что такое REST?
  • Что такое SOAP?
  • Чем отличаются REST и SOAP?

REST и SOAP

REST и SOAP на самом деле не сопоставимы. REST — это архитектурный стиль. SOAP — это формат обмена сообщениями. Давайте сравним популярные реализации стилей REST и SOAP.

  • Пример реализации RESTful: JSON через HTTP
  • Пример реализации SOAP: XML поверх SOAP через HTTP

На верхнем уровне SOAP ограничивает структуры ваших сообщений, тогда как REST — это архитектурный подход, ориентированный на использование HTTP в качестве транспортного протокола.

  • Специфика SOAP — это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML, включающий:
    — Envelope (конверт) – корневой элемент, который определяет сообщение и пространство имен, использованное в документе,
    — Header (заголовок) – содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации,
    — Body (тело) – содержит сообщение, которым обмениваются приложения,
    — Fault – необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений. И запрос, и ответ должны соответствовать структуре SOAP.
  • Специфика REST — использование HTTP в качестве транспортного протокола. Он подразумевает наилучшее использование функций, предоставляемых HTTP — методы запросов, заголовки запросов, ответы, заголовки ответов и т. д.

Формат обмена сообщениями

  • В SOAP вы используете формат SOAP XML для запросов и ответов.
  • В REST такого фиксированного формата нет. Вы можете обмениваться сообщениями на основе XML, JSON или любого другого удобного формата. JSON является самым популярным среди используемых форматов.

Определения услуг

  • SOAP использует WSDL (Web Services Description Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML.
  • REST не имеет стандартного языка определения сервиса. Несмотря на то, что WADL был одним из первых предложенных стандартов, он не очень популярен. Более популярно использование Swagger или Open API.

Транспорт

SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете использовать либо Web протокол HTTP, либо MQ.

REST подразумевает наилучшее использование транспортного протокола HTTP

Простота реализации

RESTFful веб-сервисы, как правило, гораздо проще реализовать, чем веб-сервисы на основе SOAP.

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

По этому вопросу также имеется авторское

видео

.

Резюме

В этой статье мы подробно рассмотрели различия между REST и SOAP.

Дополнительное чтение


5 Courses to Learn RESTful Web Services With Java and Spring in 2019

10 API Testing Tips for Beginners (SOAP and REST)

REST и SOAP. Почувствуйте разницу

Некоторое время назад я гуглил по поводу “REST vs SOAP”, прочитал пару статей и вроде бы все понял, но не почувствовал от этого никакого удовлетворения. Что-то было не так, то ли я не почувствовал основную идею, то ли просто читал, одновременно слушая конференцию Зава и думая о новой фиче в проекте. Поэтому, когда увидел в рассылке вопрос о том, кто мог бы организовать что-то образовательное по теме REST, я сразу же увидел в этом личную выгоду разобраться в теме поглубже. Пройдя кастинг, приступил к задаче. Пару месяцев назад при беглом изучении вопроса я понял о REST примерно следующее:

  • Все является ресурсами с уникальным идентификатором (URL).
  • Все операции клиента с сервером stateless, т. е. сервер не должен хранить вообще никакой информации о клиенте – никакой сессии.
  • Все запросы можно поделить на 4 типа в соответствии с CRUD, причем каждому типу сопоставляется HTTP метод – Post, Get, Put и Delete.
  • Вся логика крутится вокруг ресурсов, а не операций.

Денис Афанасьев

Аббревиатура REST – дурацкая, запутывающая и по сути ничего не объясняющая. Айтишники вообще породили массу дурацких названий, можно вспомнить ActiveX или ASP…

Вот с такими воспоминаниями я начал бороздить просторы Интернета. Первой мыслью было: а почему выбрано название REST? Representational State Transfer, в переводе википедии «передача состояния представления»… Никакая картинка в голове не вырисовывается даже при четвертом вчитывании. Здесь пытаются ответить на мой вопрос и даже ссылаются на то, как Рой Филдинг (человек, сформулировавший принципы REST) сам объяснял происхождение названия.
Мысль сводится к тому, что запрос ресурса с сервера переводит клиентское приложение в определенное состояние (state), а запрос следующего ресурса меняет состояние приложения (transfer). А “Representational” означает то, что ресурс возвращается не просто так, а в каком-то представлении, например в представлении для машины или в представлении для человека. Сложно, как по мне, и сбивает с толку, т.к. состояние – это как раз то, что отсутвует в отношениях клиент-сервер в архитектуре REST.

Я бы назвал как-то вроде «Стандартизированное оперирование данными», вот только сначала надо что-то придумать, а потом уже яркое название выбирать. А Филдинг в своей диссертации признается, что название придумано не для того, чтобы было понятно, о чем речь а «is intended to evoke an image of how a well-designed Web application behaves».

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

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

  • Give every “thing” an ID.
    Очччень желательно.
  • Link things together.
    Например, в страницу (представление) о Mercedes C218 хорошо бы добавить ссылку на страницу конкретно о двигателе данной модели, чтобы желающие могли сразу туда перейти, а не тратить время на поиск этой самой страницы.
  • Use standard methods.
    Имеется в виду, экономьте свои силы и деньги заказчика, используйте стандартные методы HTTP, например GET http://www.example.com/cars/00345 для получения данных вместо определения собственных методов вроде getCar?id=00345.
  • Resources can have multiple representations.
    Одни и те же данные можно вернуть в XML или JSON для программной обработки или обернутыми в красивый дизайн для просмотра человеком.
  • Communicate statelessly.
    Да, RESTful сервис должен быть как идеальный суд – его не должно интересовать ни прошлое подсудимого (клиента), ни будущее – он просто выносит приговор (отвечает на запрос).

Только что употребленный термин RESTful (веб-)сервис всего лишь означает сервис, реализованный с использованием принципов REST. Так что же нам дает следование эти самым принципам REST? Для начала я бы назвал простоту основным преимуществом архитектуры REST. Простоту идеи, простоту разработки и добавления функциональности к RESTful-приложениям. Идея настолько проста и универсальна, что ее даже сложно сначала уловить. Мы не добавляем никакого нового нового слоя в наш и без того многослойный программерский пирог, а просто используем уже давно признанные стандарты. Поэтому чтобы ответить на вопрос о преимуществах и недостатках и чтобы анализ имел больше смысла, предлагаю перейти к сравнению подходов SOAP и REST.

  1. SOAP – это целое семейство протоколов и стандартов, откуда напрямую вытекает, что это более тяжеловесный и сложный вариант с точки зрения машинной обработки. Поэтому REST работает быстрее.
  2. SOAP используют HTTP как транспортный протокол, в то время как REST базируется на нем. Это означает, что все существующие наработки на базе протокола HTTP, такие как кеширование на уровне сервера, масштабирование, продолжают так же работать в REST архитектуре, а для SOAP необходимо искать другие средства. Взамен этого SOAP сервисы получают такое мифическое свойство, как возможность работать с любым протоколом транспортного уровня вместо HTTP, однако практической пользы от него зачастую не больше, чем сотрудникам Челябинского трубопрокатного завода от большого количества статей в википедиях на мертвых языках
  3. Есть мнение, что разработка RESTful сервисов намного проще. Наверное, это правда, если использовать Notepad в качестве основной среды разработки, но вот с использованием наших чудесных средств разработки, я позволю себе усомниться в верности этого утверждения.
  4. В первом гугловском результате по запросу «REST vs SOAP» акцентируется внимание на том, что ответ REST может быть представлен в различных форматах, а SOAP привязан к XML. Это действительно важный фактор, достаточно представить себе вызов сервиса из javascript, ответ на который мы определенно хотим получать в JSON.
  5. «REST vs SOAP» можно перефразировать в «Простота vs Стандарты», что проявляется в том, что для SOAP мы имеем протокол WSDL для исчерпывающего описания веб-сервиса, который с использованием все тех же чудесных средств разработки прото-таки волшебным образом делает почти всю работу за нас. Со стороны REST мы имеем загадочный и неиспользуемый протокол WADL, который в принципе и не нужен – он мешает простоте.
  6. Второй аспект предыдущего пункта – обработка ошибок. В SOAP она полностью стандартизована, а REST может использовать давно известные коды ошибок HTTP (если здесь Вас посетила мысль, что это же очевидно и зачем я это пишу, то значит Вы внимательно читаете статью).
  7. То, с чего можно было бы начать, но я припас напоследок. Это одна из ключевых мыслей. SOAP работает с операциями, а REST – с ресурсами. Этот факт в совокупности с отсутствием клиентского состояния у RESTful сервисов приводит нас к тому, что такие вещи как транзакции или другая сложная логика должна реализовываться «SOAP-но». Приведу пару примеров на понимание разницы между подходами. Букмекерская контора заказала сервис для работы с футбольной статистикой. Пользовательский функционал – получить список матчей, получить детали о матче. Для редакторов – редактировать (Create, Edit, Delete) список матчей, редактировать детали матча. Для такой задачи однозначно надо выбирать подход REST и получать бенефиты от его простоты и естественности во взаимодействии с HTTP. Не нужны нам здесь SOAP-конверты, SOAP-главпочтамты и SOAP-авиапочта, которая может использовать любую марку самолета. Нам всего лишь надо реализовать следующее:
Что происходит при обращении с использованием методов HTTP
URLGETPOSTPUTDELETE
example.com/matchesПолучаем список матчейСоздаем заново список матчейОбновляем список матчейМстим директору букмекерской конторы
example.com/matches/28Получаем детали матча с ID=28Создаем информацию о матчеОбновляем детали матчаУдаляем матч

Все очень просто! Теперь пример посложнее. Та же букмекерская контора захотела API для ставок на live матчи. Эта процедура включает в себя многочисленные проверки, например, продолжает ли ставка быть актуальной, не изменился ли коэффициент, не превышена ли максимальная сумма ставки для маркета. После этого происходит денежная транзакция, результаты которой записываются в основную и в резервные базы данных. Лишь после этого клиенту приходит ответ об успешности операции. Здесь явно прослеживается ориентация на операции, имеются повышенные требования к безопасности и устойчивости приложения, поэтому целесообразно использовать SOAP.
И еще пару задач для того, чтобы почувствовать тему:

  • Футбольный клуб заказывает CMS для подробных сведений об игроках команды-неприятеля. Нужен функционал добавления характеристик игрока простыми пользователями прямо во время матча с последующей интеграцией с табло стадиона, на котором необходимо в реальном времени отображать комментарии.
  • Мексиканский наркобарон Педро Гонсалес заказывает API для учета продаж героина в Юго-Западных штатах США. Он особо просит мобильное приложение под эту задачу, т.к. его бизнес часто проходит на открытом воздухе, где нету других вариантов выхода в сеть.
  • Анонимный миллиардер очень хочет такую программу, которая бы ему показывала всех его любовниц в городе, в котором он сейчас находится и то, какой текущий статус отношений. Он хочет интегрировать эту программу с уже существующим его личным десктопным приложением для подбора мест для отдыха, он очень хочет большую красную надпись о возможных неприятностях в окошке, где предлагаются варианты авиаперелета.
Какие подходы вы бы использовали в данных задачах? Хотел я еще написать про то, что это все дает .NET разработчику и как это использовать в своих целях, однако вижу, что индекс нудности статьи приближается к критическому, поэтому ограничусь анонсом семинара, который будет продолжением данной статьи и планируется вскоре после выхода номера газеты. С целью понижения все того же показателя я намеренно избегал аспектов безопасности и, например, ответа на вопрос ”А как вообще возможна аутентификация в архитектуре REST, если читателю на протяжении всей этой статьи внушалось, что RESTful сервис должен быть stateless?”. А выводы статьи будут следующими:
  • Филдинг со своими принципами REST ничего не изобрел, а просто собрал в одну диссертацию то, что уже существовало в каком-то виде и изложил то, как можно получать максимальную выгоду из уже сформировавшейся архитектуры сети.
  • SOAP и REST – не конкуренты. Они представляют разные весовые категории и вряд ли найдется задача, для которой будет сложно сказать, какой подход рациональнее использовать – SOAP или REST. Поэтому «религиозные» убеждения в вопросах выбора архитектуры для веб-сервиса вряд ли будут полезны. Для тех, кто не знает, с чего начать анализ задачи, могу порекомендовать эту презентацию. У них чаще побеждает REST.

Введение в SOAP

[Disclaimer: Данная статья была переведена в рамках «Конкурса на лучший перевод статьи» на сервисе Quizful. Ссылка на оригинал находится внизу страницы.]

Что такое SOAP?

SOAP расшифровывается как Simple Object Access Protocol (Простой Протокол Доступа к Объектам). Надеюсь по прочтении статьи вам останется только недоумевать: «Что за странное название?»

SOAP в теперешней его форме – это метод удаленного вызова (RPC, Remote procedure Call) по сети. (Да, он также используется для передачи документов в виде XML, но мы это пока опустим).

Давайте разбираться. Представьте, что у вас есть сервис, который возвращает биржевую котировку (stock quote) для заданного тикера (stock symbol). Он посылает данные на сайт Nasdaq и формирует на основе возвращенного HTML нужный результат. Дальше, чтобы позволить другим разработчикам использовать его внутри своих приложений, вы делаете из этого сервиса компонент, который через Интернет находит информацию о котировках. Работает он отлично, пока в один прекрасный день Nasdaq не меняет разметку своих страниц. Вам приходится пересмотреть всю логику работы компонента и разослать обновления всем разработчикам, использующим его. А им в свою очередь необходимо разослать обновления всем своим пользователям. Если это происходит на более-менее постоянной основе, вы можете нажить немало врагов среди коллег-разработчиков. А с программистами, как известно, шутки плохи. Вы же не хотите завтра доставать фотографию любимого кота из офисного шредера, правда?

Что же делать? Посмотрим… все, что вам нужно, это предоставить одну функцию, которая будет принимать на вход тикер (типа string) и возвращать биржевую котировку (типа float или double). Так не проще ли было бы просто позволить вашим разработчикам каким-то образом вызвать эту функцию через Интернет? Отлично! Тоже мне новость, есть же COM и Corba, и Java, которые этим занимаются уже годами… что правда – то правда, но эти методы не без изъяна. Удаленная настройка COM не тривиальна. Кроме того, нужно открыть столько портов в брандмауэре, что на системного администратора пива не напасешься. Да, и придется забыть о пользователях всех операционных систем кроме Windows. Но ведь позьзователи Linux тоже иногда интересуются биржей.

Хотя, похоже, что не все потеряно для пользователей Linux, если они используют DCOM, больше здесь: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.

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

SOAP – это стандарт, который позволяет вам описать такой удаленный вызов и вид, в котором будет возвращаться результат. Таким образом вам нужно разместить вашу функцию в приложении, доступном по сети и получать вызовы в виде SOAP пакетов. После этого вы валидируете входные данные, запускаете вашу функцию и возвращаете результат в новом SOAP пакете. Весь процесс может работать через HTTP, так что вам не придется открывать кучу портов в брандмауэре. Правда просто?

О чем эта статья

Это первая из серии статей о SOAP, которые мы пишем в Agni Software. В этой статье я постараюсь дать вам представление о том, что такое SOAP и как написать приложение, общающееся с SOAP сервером.

Soap и XML

Если вам SOAP пока еще кажется простым, добавим XML. Теперь вместо имени функции и параметров мы получаем довольно сложный XML-конверт, как будто созданный для того, чтобы сбить вас с толку. Но не спешите пугаться. Дальше – больше, и вам нужно увидеть всю картину, чтобы оценить всю сложность SOAP.
Если вы не знаете, что такое XML, для начала прочтите мою статью об XML здесь: http://www.agnisoft.com/white_papers/xml_delphi.asp.

Все SOAP пакеты имеют XML формат. Что это значит? Посмотрим. Взгляните на эту функцию (Pascal):

function GetStockQuote( Symbol : string ) : double;
Выглядит отлично, но проблема в том, что это – Pascal. Какая польза от этого простого определения для Java-разработчика? Или для кого-то, кто работает с VB? Нам нужно что-то, что будет понятно всем, даже VB-программистам. Так дайте им XML, содержащий одну и ту же инфрмацию (параметры, значения биржевых котировок и т.д.). Вы создаете SOAP пакет, который по сути является вызовом вашей функции, обернутый в XML, чтобы любое приложения на любой платформе могло его понять. Теперь посмотрим, как выглядит наш SOAP вызов:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:GetStockQuote xmlns:ns1="urn:xmethods-quotes">
<SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<symbol xsi:type="xsd:string">IBM</symbol> 
</ns1:GetStockQuote> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope>
Информативно, правда? SOAP упрощается на глазах. Ладно, шутки в сторону. Теперь я постараюсь объяснить вам, как разобраться в этом SOAP вызове.

Расшифровка тегов

Первый тег, который бросается в глаза – это . Этот тег – внешняя оболочка SOAP пакета, содержащая несколько объявлений пространств имен, которые нас особо не интересуют, но очень важны для любого языка программирования или парсера. Пространства имен определяются для того, чтобы последующие префиксы, такие как «SOAP-ENV:» или «xsd:» воспринимались парсером.

Следующий тег – <SOAP-ENV:Body>. (Мы пропустили тег, не представленный здесь – <SOAP-ENV:Header>. Его нет в этом конкретном примере, но если вы хотите почитать о нем больше, обратитесь к спецификации SOAP здесь: http://www.w3.org/TR/SOAP/). Тег <SOAP-ENV:Body> собственно и содержит SOAP вызов.

Следующий тег в списке – <ns1:GetStockQuote …>. Имя тега, GetStockQuote и есть вызываемая функция. Согласно терминологии SOAP, это называется операцией. Таким образом GetStockQuote – операция, которая должна быть выполнена. ns1 – это пространство имен, указывающее на urn:xmethods-quotes в нашем случае.

Лирическое отступление на счет пространств имен: Пространство имен дает возможность квалифицировать XML тег. Нельзя, к примеру, иметь две переменные с одинаковым именем в одной процедуре, но если они в двух разных процедурах, проблем не возникает. Таким образом процедура – это пространство имен, так как все имена в ней уникальны. Точно так же XML теги имеют свою область видимости внутри пространств имен, так что имея пространство имен и имя тега, можно однозначно его идентифицировать. Мы определим пространство имен как URI, чтобы отличать наш NS1 от подражателей. В приведенном выше примере NS1 – это алиас, указывающий на urn:xmethods-quotes.

Обратите внимание также на атрибут encodingStyle – этот атрибут определяет каким образом сериализуется SOAP вызов.

Внутри тега <GetStockQuote> содержатся параметры. В нашем простейшем случаи у нас есть только один параметр – тег <symbol>. Обратите внимание на эту строку возле тега:

xsi:type="xsd:string"
Приблизительно так в XML и определяются типы. (Обратите внимание на то, как хитро я использовал слово «приблизительно», делая обобщение о технологии, которая может измениться как только статья будет опубликована). Что конкретно это означает: тип, определенный в пространстве имен xsi, который, как вы заметили, определен в теге – xsd:string. А это в свою очередь string, определенный в пространстве имен xsd, опять-таки, определенном ранее. (Уверен, юристы бы от этого всего просто млели).

Внутри тега <symbol> указано «IBM». Это – значение параметра symbol функции GetStockQuote.

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

Вот и разобрались с SOAP пакетом, определяющим вызов к SOAP серверу. А SOAP сервер с помощью XML парсеров, красной кнопки и космической станции «МИР» декодирует этот вызов и определяет, что вам нужна биржевая котировка. Он тут же находит нужную котировку и возвращает вам ее в таком виде:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetStockQuoteResponse xmlns:m="urn:xmethods-quotes">
<Price>34.5</Price>
</m:GetStockQuoteResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
После разворачивания SOAP конверта, срывания ленточек и шуршания оберткой, мы узнаем, что цена акции IBM – 34.5.

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

Таким образом мы знаем, чего ожидает SOAP сервер и что он вернет. Так КАК же отправить эту информацию? Использовать можно любой транспорт. Самым освещенным является HTTP. Я не стану вдаваться в подробности HTTP, для тех, кто не знает – это то, что использует ваш браузер, чтобы общаться с сайтами, на которые вы заходите.

Нужный HTTP запрос будт выглядеть приблизительно так:

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
...the soap request packet here...
Единственное, что еще стоит отметить – это заголовок SOAPAction. Этот заголовок указывает на цель запроса и является обязательным. Каждый SOAP сервер может иметь неограниченное количество функций и может использовать заголовок SOAPAction чтобы определить какую функцию вызывают. Брандмауэры и мультиплексоры также могут фильтровать контент на основании этого заголовка.

SOAP ответ от HTTP сервера будет выглядеть следующим образом:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
...Soap Response packet here...
Почему HTTP? Во-первых, сетевым администраторам не придется открывать уйму отдельных портов для SOAP вызовов… веб-сервер может спокойно обрабатывать вызовы, т.к. 80-й порт обычно открыт для всех для приема входящих запросов. Еще одним преимуществом является расширяемость веб-серверов с помощью CGI, ISAPI и других нативных модулей. Эта расширяемость позволяет написать модуль, обрабатывающий SOAP запросы не задевая другого веб-контента.

Вот и все

Надеюсь, эта статья помогла пролить немного света на SOAP. Если вы еще здесь и хотите почитать больше на эту тему, посетите сайт авторов: http://www.agnisoft.com/soap

———-
Оригинальный текст статьи: Introduction to SOAP

SOAP — Краткое руководство — CoderLessons.com

SOAP — это сокращение от Simple Object Access Protocol. Это протокол обмена сообщениями на основе XML для обмена информацией между компьютерами. SOAP является приложением спецификации XML.

Указывает на заметку

  • SOAP — это протокол связи, предназначенный для связи через Интернет.

  • SOAP может расширить HTTP для обмена сообщениями XML.

  • SOAP обеспечивает транспорт данных для веб-сервисов.

  • SOAP может обмениваться полными документами или вызывать удаленную процедуру.

  • SOAP может использоваться для трансляции сообщения.

  • SOAP не зависит от платформы и языка.

  • SOAP — это способ определения, какая информация отправляется и каким образом.

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

SOAP — это протокол связи, предназначенный для связи через Интернет.

SOAP может расширить HTTP для обмена сообщениями XML.

SOAP обеспечивает транспорт данных для веб-сервисов.

SOAP может обмениваться полными документами или вызывать удаленную процедуру.

SOAP может использоваться для трансляции сообщения.

SOAP не зависит от платформы и языка.

SOAP — это способ определения, какая информация отправляется и каким образом.

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

Хотя SOAP может использоваться в различных системах обмена сообщениями и может доставляться через различные транспортные протоколы, первоначальная цель SOAP — удаленные вызовы процедур, транспортируемые через HTTP.

Другие платформы, в том числе CORBA, DCOM и Java RMI, предоставляют функциональность, аналогичную SOAP, но сообщения SOAP написаны полностью на XML и поэтому уникально независимы от платформы и языка.

SOAP-сообщение — это обычный XML-документ, содержащий следующие элементы:

  • Конверт — определяет начало и конец сообщения. Это обязательный элемент.

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

  • Тело — содержит данные XML, содержащие отправляемое сообщение. Это обязательный элемент.

  • Неисправность — необязательный элемент неисправности, который предоставляет информацию об ошибках, возникающих при обработке сообщения.

Конверт — определяет начало и конец сообщения. Это обязательный элемент.

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

Тело — содержит данные XML, содержащие отправляемое сообщение. Это обязательный элемент.

Неисправность — необязательный элемент неисправности, который предоставляет информацию об ошибках, возникающих при обработке сообщения.

Все эти элементы объявлены в пространстве имен по умолчанию для конверта SOAP — http://www.w3.org/2001/12/soap-envelope, а пространство имен по умолчанию для кодировки SOAP и типов данных — http: //www.w3 .org / 2001/12 / мыла-кодирования

ПРИМЕЧАНИЕ. — Все эти характеристики могут быть изменены. Так что продолжайте обновлять себя новейшими спецификациями, доступными на сайте W3.

Структура сообщения SOAP

Следующий блок отображает общую структуру сообщения SOAP —

<?xml version = "1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Header>
      ...
      ...
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
      ...
      ...
      <SOAP-ENV:Fault>
         ...
         ...
      </SOAP-ENV:Fault>
      ...
   </SOAP-ENV:Body>
</SOAP_ENV:Envelope>

Конверт SOAP указывает начало и конец сообщения, чтобы получатель знал, когда было получено все сообщение. Конверт SOAP решает проблему определения того, когда вы получили сообщение и готовы его обработать. Поэтому конверт SOAP — это, по сути, механизм упаковки.

Указывает на заметку

  • Каждое сообщение SOAP имеет корневой элемент Envelope.

  • Конверт является обязательной частью сообщения SOAP.

  • Каждый элемент Envelope должен содержать ровно один элемент Body.

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

  • Конверт изменяется при изменении версий SOAP.

  • Конверт SOAP указывается с использованием префикса пространства имен ENV и элемента Envelope.

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

  • SOAP-процессор, совместимый с v1.1, генерирует ошибку при получении сообщения, содержащего пространство имен конверта v1.2.

  • SOAP-процессор, совместимый с v1.2, генерирует ошибку VersionMismatch, если он получает сообщение, которое не включает пространство имен конверта v1.2.

Каждое сообщение SOAP имеет корневой элемент Envelope.

Конверт является обязательной частью сообщения SOAP.

Каждый элемент Envelope должен содержать ровно один элемент Body.

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

Конверт изменяется при изменении версий SOAP.

Конверт SOAP указывается с использованием префикса пространства имен ENV и элемента Envelope.

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

SOAP-процессор, совместимый с v1.1, генерирует ошибку при получении сообщения, содержащего пространство имен конверта v1.2.

SOAP-процессор, совместимый с v1.2, генерирует ошибку VersionMismatch, если он получает сообщение, которое не включает пространство имен конверта v1.2.

v1.2-совместимое сообщение SOAP

Ниже приведен пример сообщения SOAP, совместимого с v1.2.

<?xml version = "1.0"?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">
   ...
   Message information goes here
   ...
</SOAP-ENV:Envelope>

SOAP с HTTP POST

В следующем примере показано использование сообщения SOAP в операции HTTP POST, которая отправляет сообщение на сервер. Он показывает пространства имен для определения схемы конверта и для определения схемы правил кодирования. Ссылка OrderEntry в заголовке HTTP — это имя программы, которая будет вызываться на веб-сайте tutorialspoint.com.

POST /OrderEntry HTTP/1.1
Host: www.tutorialspoint.com
Content-Type: application/soap; charset = "utf-8"
Content-Length: nnnn

<?xml version = "1.0"?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">
   ...
   Message information goes here
   ...
</SOAP-ENV:Envelope>

ПРИМЕЧАНИЕ. — Привязка HTTP указывает местоположение службы.

Необязательный элемент Header предлагает гибкую структуру для указания дополнительных требований уровня приложения. Например, элемент Header может использоваться для указания цифровой подписи для служб, защищенных паролем. Кроме того, его можно использовать для указания номера учетной записи для сервисов SOAP с оплатой за использование.

Указывает на заметку

  • Это необязательная часть сообщения SOAP.

  • Элементы заголовка могут встречаться несколько раз.

  • Заголовки предназначены для добавления новых функций и возможностей.

  • Заголовок SOAP содержит записи заголовка, определенные в пространстве имен.

  • Заголовок закодирован как первый непосредственный дочерний элемент конверта SOAP.

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

Это необязательная часть сообщения SOAP.

Элементы заголовка могут встречаться несколько раз.

Заголовки предназначены для добавления новых функций и возможностей.

Заголовок SOAP содержит записи заголовка, определенные в пространстве имен.

Заголовок закодирован как первый непосредственный дочерний элемент конверта SOAP.

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

Атрибуты заголовка SOAP

Заголовок SOAP может иметь следующие два атрибута:

Атрибут актера

Протокол SOAP определяет путь сообщения как список узлов службы SOAP. Каждый из этих промежуточных узлов может выполнить некоторую обработку и затем переслать сообщение следующему узлу в цепочке. Устанавливая атрибут Actor, клиент может указать получателя заголовка SOAP.

Атрибут MustUnderstand

Указывает, является ли элемент Header необязательным или обязательным. Если установлено значение true, получатель должен понимать и обрабатывать атрибут Header в соответствии с его определенной семантикой или возвращать ошибку.

В следующем примере показано, как использовать заголовок в сообщении SOAP.

<?xml version = "1.0"?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = " http://www.w3.org/2001/12/soap-envelope"   
   SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Header>
      <t:Transaction 
         xmlns:t = "http://www.tutorialspoint.com/transaction/" 
         SOAP-ENV:mustUnderstand = "true">5
      </t:Transaction>
   </SOAP-ENV:Header>
   ...
   ...
</SOAP-ENV:Envelope>

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

Тело определяется как дочерний элемент оболочки, а семантика для тела определяется в связанной схеме SOAP.

Тело содержит обязательную информацию, предназначенную для конечного получателя сообщения. Например —

<?xml version = "1.0"?>
<SOAP-ENV:Envelope>
   ........
   <SOAP-ENV:Body>
      <m:GetQuotation xmlns:m = "http://www.tp.com/Quotation">
         <m:Item>Computers</m:Item>
      </m:GetQuotation>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

В приведенном выше примере запрашивается расценка компьютерных комплектов. Обратите внимание, что элементы m: GetQuotation и Item выше являются специфичными для приложения элементами. Они не являются частью стандарта SOAP.

Вот ответ на вышеуказанный запрос —

<?xml version = "1.0"?>
<SOAP-ENV:Envelope>
   ........
   <SOAP-ENV:Body>
      <m:GetQuotationResponse xmlns:m = "http://www.tp.com/Quotation">
         <m:Quotation>This is Qutation</m:Quotation>
      </m:GetQuotationResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Обычно приложение также определяет схему, содержащую семантику, связанную с элементами запроса и ответа.

Сервис Quotation может быть реализован с использованием EJB, работающего на сервере приложений; в этом случае процессор SOAP будет отвечать за отображение информации тела в качестве параметров в и из реализации EJB службы GetQuotationResponse . Процессор SOAP также может отображать информацию тела в объект .NET, объект CORBA, программу COBOL и так далее.

Если во время обработки возникает ошибка, ответ на сообщение SOAP является элементом ошибки SOAP в теле сообщения, и ошибка возвращается отправителю сообщения SOAP.

Механизм сбоя SOAP возвращает конкретную информацию об ошибке, включая предопределенный код, описание и адрес процессора SOAP, который сгенерировал сбой.

Указывает на заметку

  • Сообщение SOAP может содержать только один блок отказа.

  • Ошибка является необязательной частью сообщения SOAP.

  • Для привязки HTTP успешный ответ связан с диапазоном кодов состояния от 200 до 299.

  • Ошибка SOAP связана с диапазоном кодов состояния от 500 до 599.

Сообщение SOAP может содержать только один блок отказа.

Ошибка является необязательной частью сообщения SOAP.

Для привязки HTTP успешный ответ связан с диапазоном кодов состояния от 200 до 299.

Ошибка SOAP связана с диапазоном кодов состояния от 500 до 599.

Подэлементы неисправности

Ошибка SOAP имеет следующие подэлементы —

Sr.No Подэлемент и описание
1

<faultCode>

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

2

<faultString>

Это текстовое сообщение, объясняющее ошибку.

3

<faultActor>

Это текстовая строка, указывающая, кто вызвал ошибку. Это полезно, если сообщение SOAP проходит через несколько узлов в пути сообщения SOAP, и клиент должен знать, какой узел вызвал ошибку. Узел, который не действует как конечный пункт назначения, должен включать элемент faultActor .

4

<подробно>

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

<faultCode>

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

<faultString>

Это текстовое сообщение, объясняющее ошибку.

<faultActor>

Это текстовая строка, указывающая, кто вызвал ошибку. Это полезно, если сообщение SOAP проходит через несколько узлов в пути сообщения SOAP, и клиент должен знать, какой узел вызвал ошибку. Узел, который не действует как конечный пункт назначения, должен включать элемент faultActor .

<подробно>

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

Коды ошибок SOAP

Определенные ниже значения faultCode должны использоваться в элементе faultcode при описании неисправностей.

Sr.No Ошибка и описание
1

SOAP-ENV: VersionMismatch

Обнаружено недопустимое пространство имен для элемента конверта SOAP.

2

SOAP-ENV: MustUnderstand

Непосредственный дочерний элемент элемента Header с атрибутом mustUnderstand, установленным в «1», не был понят.

3

SOAP-ENV: Клиент

Сообщение было неправильно сформировано или содержало неверную информацию.

4

SOAP-ENV: Сервер

Возникла проблема с сервером, поэтому сообщение не удалось продолжить.

SOAP-ENV: VersionMismatch

Обнаружено недопустимое пространство имен для элемента конверта SOAP.

SOAP-ENV: MustUnderstand

Непосредственный дочерний элемент элемента Header с атрибутом mustUnderstand, установленным в «1», не был понят.

SOAP-ENV: Клиент

Сообщение было неправильно сформировано или содержало неверную информацию.

SOAP-ENV: Сервер

Возникла проблема с сервером, поэтому сообщение не удалось продолжить.

Пример ошибки SOAP

Следующий код является примером неисправности. Клиент запросил метод с именем ValidateCreditCard , но служба не поддерживает такой метод. Это представляет ошибку запроса клиента, и сервер возвращает следующий ответ SOAP —

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
   xmlns:xsd = "http://www.w3.org/1999/XMLSchema">

   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode xsi:type = "xsd:string">SOAP-ENV:Client</faultcode>
         <faultstring xsi:type = "xsd:string">
            Failed to locate method (ValidateCreditCard) in class (examplesCreditCard) at
               /usr/local/ActivePerl-5.6/lib/site_perl/5.6.0/SOAP/Lite.pm line 1555.
         </faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP включает в себя встроенный набор правил для кодирования типов данных. Это позволяет сообщению SOAP указывать конкретные типы данных, такие как целые числа, числа с плавающей запятой, двойные числа или массивы.

  • Типы данных SOAP делятся на две широкие категории — скалярные типы и составные типы.

  • Скалярные типы содержат ровно одно значение, такое как фамилия, цена или описание продукта.

  • Составные типы содержат несколько значений, таких как заказ на покупку или список котировок акций.

  • Типы соединений далее подразделяются на массивы и структуры.

  • Стиль кодирования для сообщения SOAP устанавливается через атрибут SOAP-ENV: encodingStyle .

  • Чтобы использовать кодировку SOAP 1.1, используйте значение http://schemas.xmlsoap.org/soap/encoding/

  • Чтобы использовать кодировку SOAP 1.2, используйте значение http://www.w3.org/2001/12/soap-encoding

  • Последняя спецификация SOAP принимает все встроенные типы, определенные XML-схемой. Тем не менее, SOAP поддерживает свое собственное соглашение для определения конструкций, не стандартизированных XML-схемой, таких как массивы и ссылки.

Типы данных SOAP делятся на две широкие категории — скалярные типы и составные типы.

Скалярные типы содержат ровно одно значение, такое как фамилия, цена или описание продукта.

Составные типы содержат несколько значений, таких как заказ на покупку или список котировок акций.

Типы соединений далее подразделяются на массивы и структуры.

Стиль кодирования для сообщения SOAP устанавливается через атрибут SOAP-ENV: encodingStyle .

Чтобы использовать кодировку SOAP 1.1, используйте значение http://schemas.xmlsoap.org/soap/encoding/

Чтобы использовать кодировку SOAP 1.2, используйте значение http://www.w3.org/2001/12/soap-encoding

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

Скалярные Типы

Для скалярных типов SOAP принимает все встроенные простые типы, указанные в спецификации XML-схемы. Это включает в себя строки, числа с плавающей запятой, двойные и целые числа.

В следующей таблице перечислены основные простые типы, взятые из XML-схемы, часть 0 — учебник http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/.

Простые типы, встроенные в XML-схему
Простой тип Примеры)
строка Подтвердите, что это электрический.
логический правда, ложь, 1, 0.
поплавок -INF, -1E4, -0,0, 12,78E-2, 12, INF, NaN.
двойной -INF, -1E4, -0,0, 12,78E-2, 12, INF, NaN.
десятичный -1,23, 0, 123,4, 1000,00.
двоичный 100010
целое число -126789, -1, 0, 1, 126789.
nonPositiveInteger -126789, -1, 0.
negativeInteger -126789, -1.
долго -1, 12678967543233
ИНТ -1, 126789675
короткая -1, 12678
байт -1, 126
nonNegativeInteger 0, 1, 126789
unsignedLong 0, 12678967543233
Целочисленный Беззнаковый 0, 1267896754
unsignedShort 0, 12678
unsignedByte 0, 126
положительное число 1, 126789.
Дата 1999-05-31, — 05.
время 13: 20: 00.000, 13: 20: 00.000-05: 00

Например, вот ответ SOAP с двойным типом данных —

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">
   
   <SOAP-ENV:Body>
      <ns1:getPriceResponse 
         xmlns:ns1 = "urn:examples:priceservice"  
         SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">
         <return xsi:type = "xsd:double">54.99</return>
      </ns1:getPriceResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Типы соединений

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

Чтобы создать массив, вы должны указать его как массив xsi: type . Массив также должен включать атрибут arrayType . Этот атрибут необходим для указания типа данных для содержащихся элементов и измерений массива.

Например, следующий атрибут задает массив из 10 двойных значений —

arrayType = "xsd:double[10]"

В противоположность этому следующий атрибут задает двумерный массив строк:

arrayType = "xsd:string[5,5]"

Вот пример ответа SOAP с массивом двойных значений:

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">

   <SOAP-ENV:Body>
      <ns1:getPriceListResponse 
         xmlns:ns1 = "urn:examples:pricelistservice"  
         SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

         <return xmlns:ns2 = "http://www.w3.org/2001/09/soap-encoding"  
            xsi:type = "ns2:Array" ns2:arrayType = "xsd:double[2]">
            <item xsi:type = "xsd:double">54.99</item>
            <item xsi:type = "xsd:double">19.99</item>
         </return>
      </ns1:getPriceListResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Структуры содержат несколько значений, но каждый элемент указан с уникальным элементом доступа. Например, рассмотрим элемент в каталоге продуктов. В этом случае структура может содержать SKU продукта, название продукта, описание и цену. Вот как такая структура будет представлена ​​в сообщении SOAP:

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">

   <SOAP-ENV:Body>
      <ns1:getProductResponse
         xmlns:ns1 = "urn:examples:productservice" 
         SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">
		
         <return xmlns:ns2 = "urn:examples" xsi:type = "ns2:product">
            <name xsi:type = "xsd:string">Red Hat Linux</name>
            <price xsi:type = "xsd:double">54.99</price>
            <description xsi:type = "xsd:string">
               Red Hat Linux Operating System
            </description>
            <SKU xsi:type = "xsd:string">A358185</SKU>
         </return>
      </ns1:getProductResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

ПРИМЕЧАНИЕ. — Пожалуйста, позаботьтесь о правильном отступе при написании кода SOAP. Каждый элемент в структуре указывается с уникальным именем доступа. Например, вышеприведенное сообщение включает в себя четыре элемента доступа — имя, цена, описание и артикул. Каждый элемент может иметь свой собственный тип данных. Например, имя указывается как строка, а цена указывается как двойная.

SOAP не привязан ни к какому транспортному протоколу. SOAP может транспортироваться через SMTP, FTP, IBM MQSeries или Microsoft Message Queuing (MSMQ).

Спецификация SOAP содержит подробности только по HTTP. HTTP остается самым популярным транспортным протоколом SOAP.

SOAP через HTTP

Логично, что SOAP-запросы отправляются через HTTP-запрос, а SOAP-ответы возвращаются в содержимом HTTP-ответа. Хотя запросы SOAP можно отправлять через HTTP GET, в спецификации содержатся сведения только о HTTP POST.

Кроме того, как HTTP-запросы, так и ответы требуются для установки типа контента text / xml.

Спецификация SOAP требует, чтобы клиент предоставил заголовок SOAPAction, но фактическое значение заголовка SOAPAction зависит от реализации сервера SOAP.

Например, чтобы получить доступ к службе перевода AltaVista BabelFish, размещенной в XMethods, в качестве заголовка SOAPAction необходимо указать следующее.

urn:xmethodsBabelFish#BabelFish

Даже если серверу не требуется полный заголовок SOAPAction, клиент должен указать пустую строку («») или нулевое значение. Например —

SOAPAction: ""
SOAPAction:

Вот пример запроса, отправленного через HTTP в службу перевода XMethods Babelfish:

POST /perl/soaplite.cgi HTTP/1.0
Host: services.xmethods.com
Content-Type: text/xml; charset = utf-8
Content-Length: 538
SOAPAction: "urn:xmethodsBabelFish#BabelFish"

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/" 
   xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
   xmlns:xsd = "http://www.w3.org/1999/XMLSchema">

   <SOAP-ENV:Body>
      <ns1:BabelFish
         xmlns:ns1 = "urn:xmethodsBabelFish"
         SOAP-ENV:encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/">
         <translationmode xsi:type = "xsd:string">en_fr</translationmode>
         <sourcedata xsi:type = "xsd:string">Hello, world!</sourcedata>
      </ns1:BabelFish>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Обратите внимание на тип содержимого и заголовок SOAPAction. Также обратите внимание, что метод BabelFish требует двух параметров String. Режим перевода en_fr переводит с английского на французский.

Вот ответ от XMethods —

HTTP/1.1 200 OK
Date: Sat, 09 Jun 2001 15:01:55 GMT
Server: Apache/1.3.14 (Unix) tomcat/1.0 PHP/4.0.1pl2
SOAPServer: SOAP::Lite/Perl/0.50
Cache-Control: s-maxage = 60, proxy-revalidate
Content-Length: 539
Content-Type: text/xml

<?xml version = "1.0" encoding = "UTF-8"?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/"
   SOAP-ENV:encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
   xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsd = "http://www.w3.org/1999/XMLSchema">
   
   <SOAP-ENV:Body>
      <namesp1:BabelFishResponse xmlns:namesp1 = "urn:xmethodsBabelFish">
         <return xsi:type = "xsd:string">Bonjour, monde!</return>
      </namesp1:BabelFishResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Ответы SOAP, доставляемые через HTTP, должны следовать тем же кодам состояния HTTP. Например, код состояния 200 OK указывает на успешный ответ. Код состояния 500 Internal Server Error указывает, что произошла ошибка сервера и что ответ SOAP содержит элемент Fault.

В приведенном ниже примере запрос GetQuotation отправляется на сервер SOAP через HTTP. Запрос имеет параметр QuotationName , и в ответе будет возвращено предложение.

Пространство имен для функции определяется по адресу http://www.xyz.org/quotation .

Вот SOAP-запрос —

POST /Quotation HTTP/1.0
Host: www.xyz.org
Content-Type: text/xml; charset = utf-8
Content-Length: nnn

<?xml version = "1.0"?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Body xmlns:m = "http://www.xyz.org/quotations">
      <m:GetQuotation>
         <m:QuotationsName>MiscroSoft</m:QuotationsName>
      </m:GetQuotation>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Соответствующий SOAP-ответ выглядит так:

HTTP/1.0 200 OK
Content-Type: text/xml; charset = utf-8
Content-Length: nnn

<?xml version = "1.0"?>
<SOAP-ENV:Envelope
   xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
   SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

   <SOAP-ENV:Body xmlns:m = "http://www.xyz.org/quotation">
      <m:GetQuotationResponse>
         <m:Quotation>Here is the quotation</m:Quotation>
      </m:GetQuotationResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP 1.1 был первоначально представлен W3C в мае 2000 года. Официальными представителями были крупные компании, такие как Microsoft, IBM и Ariba, а также небольшие компании, такие как UserLand Software и DevelopMentor.

В июле 2001 года рабочая группа по протоколу XML выпустила «рабочий проект» SOAP 1.2. В рамках W3C этот документ официально находится в стадии разработки, что означает, что документ, вероятно, будет обновляться много раз, прежде чем будет завершен.

SOAP версии 1.1 доступен в Интернете по адресу http://www.w3.org/TR/SOAP/.

Рабочий проект SOAP версии 1.2 доступен по адресу http://www.w3.org/TR/soap12/.

Обратите внимание, что W3C также содержит представление для «SOAP-сообщений с вложениями», которое отделено от основной спецификации SOAP. Эта спецификация позволяет сообщениям SOAP включать двоичные вложения, такие как изображения и звуковые файлы. Для получения полной информации см. Примечание W3C по адресу http://www.w3.org/TR/SOAP-attachments .

В чем разница между SOAP и REST Web-сервисами — Разница Между

Основное различие между OAP и RET Web ervice заключается в том, что OAP (простой протокол доступа к объектам) — это протокол на основе XML, а RET (передача состояния представления) — это архитектурный

Основное различие между SOAP и REST Web Services заключается в том, что SOAP (простой протокол доступа к объектам) — это протокол на основе XML, а REST (передача состояния представления) — это архитектурный стиль.

Веб-сервис — это набор стандартов или протоколов для обмена информацией между несколькими устройствами или приложениями. Различные приложения используют различные технологии и языки программирования. Веб-сервис предоставляет общую платформу для взаимодействия этих приложений. Например, приложение Java может взаимодействовать с приложением PHP или .NET с помощью веб-служб по сети. Веб-сервис просто обеспечивает независимую от языка платформу для обеспечения связи между различными технологиями. SOAP и REST — это два типа веб-сервисов.

Ключевые области покрыты

1. Что такое SOAP
— определение, особенности, использование
2. Что такое ОТДЫХ
— определение, особенности, использование
3. Какова связь между SOAP и веб-сервисами REST?
— Схема ассоциации
4. Разница между SOAP и веб-сервисами REST
— Сравнение основных различий

Основные условия

SOAP, REST, веб-сервисы


Что такое SOAP

SOAP означает Простой протокол доступа к объектам, Это протокол на основе XML. Это позволяет приложениям, построенным на различных языках программирования и разных операционных системах, обмениваться данными друг с другом.

Рисунок 1: Веб-сервисы

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

При разработке приложения на основе SOAP важно придерживаться стандартов. Обычно они медленные; требуют больше ресурсов и большей пропускной способности. В целом, он больше подходит для приложений уровня предприятия, в которых безопасность является основной проблемой.

Что такое веб-сервисы REST?

REST означает Изобразительное State Transfer, Это не протокол. Это архитектурный паттерн. Веб-сервис, который подтверждает архитектурный стиль Rest, является веб-сервисом RESTful. ОТДЫХ проще и гибче. Эти сервисы не соответствуют строгим спецификациям, таким как SOAP. Это требует минимальной пропускной способности и ресурсов. Более того, он не зависит от языка и платформы.

REST — хороший вариант для публичного API. Почти 70% общедоступных API основаны на REST. Обычно это предпочтительнее, чем SOAP. Вкратце, это помогает создавать легкие, масштабируемые и поддерживаемые веб-сервисы.

Отношения между SOAP и веб-сервисами REST

  • Веб-сервисы REST могут использовать веб-сервисы SOAP для реализации.

Разница между SOAP и веб-сервисами REST

Определение

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

Стенды для

SOAP означает простой протокол доступа к объектам. REST расшифровывается как представительский государственный трансферт.

Тип

SOAP — это протокол сообщений на основе XML, а REST — архитектурный стиль.

Формат данных

SOAP позволяет формат XML. REST допускает различные форматы данных, такие как простой текст, XML, HTML, JSON и т. Д.

стандарты

SOAP определяет стандарты, которым необходимо строго следовать. Напротив, REST не определяет строгие стандарты, такие как SOAP.

Безопасность

SOAP более безопасен по сравнению с REST. SOAP имеет свою собственную безопасность, называемую WS-безопасностью.

Ресурсы и пропускная способность

SOAP требует большей пропускной способности и большего количества ресурсов. REST требует меньшей пропускной способности и минимальных ресурсов.

гибкость

REST проще и гибче, чем SOAP.

применимость

SOAP больше подходит для приложений уровня предприятия, а REST — хороший вариант для общедоступного API.

Заключение

Разница между Soap и Rest Web Services заключается в том, что Soap — это протокол на основе XML, а Rest — это архитектурный стиль. Программист может выбрать Soap или Rest в зависимости от языка программирования, среды и требований приложения. Независимо от того, выбирает ли программист Soap или Rest для веб-службы, важно тщательно протестировать API.

Основы SOAP — Русские Блоги

1. Что такое SOAP?

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

  1. письмо-соглашение

  2. Используется для связи между приложениями

  3. Формат сообщения

  4. Предназначен для общения через интернет

  5. Независимая платформа

  6. Независимый от языка

  7. На основе XML

  8. Простой и масштабируемый

  9. Разрешить обход брандмауэра

  10. Стандарт W3C

Простое SOAP-сообщение

 

Сложные SOAP-сообщения

 

Во-вторых, роль SOAP

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

SOAP обеспечивает структуру обмена сообщениями на основе XML

  1. Масштабируемость

    1. Простота остается одной из главных целей разработки SOAP.

    2. Простота всегда важнее эффективности или технической чистоты.

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

  2. Может использоваться на различных основных сетевых протоколах

    1. Может использовать TCP, HTTP, SMTP на любом транспортном протоколе

    2. Спецификация SOAP обеспечивает гибкую структуру для определения произвольных привязок к протоколу.

    3. Поскольку HTTP широко используется, он обеспечивает явное связывание для HTTP сегодня.

  3. Независимо от модели программирования,

    1. Разрешить любую модель программирования, независимо от удаленного вызова процедуры

    2. SOAP определяет модель для обработки одного одностороннего сообщения. SOAP допускает любое количество режимов обмена сообщениями (MEP).

    3. Из-за популярности RPC в SOAP изложены соглашения по использованию RPC с SOAP.

 

Три, пример сообщения SOAP

Запросить сообщение

<soap:Envelope>

   <soap:Body>

      <m:GetBookPrice xmlns:m="http://www.amzn.org/books" />   

        <m:BookName>Fast Food Nation</m:BookName>  

      </m:GetBookPrice>

   </soap:Body>

</soap:Envelope>

Ответное сообщение

<soap:Envelope>

   <soap:Body>

      <m:GetBookPriceResponse xmlns:m="http://www.amzn.org/books" />

  <m:Price>34.5</m:Price>

        </m:GetBookPriceResponse>

   </soap:Body>

</soap:Envelope>

4. мыльный конверт

Сообщение SOAP содержится в «конверте» XML с заголовком и телом.

Заголовок SOAP является необязательным и содержит специфическую для приложения информацию о сообщении SOAP (например, аутентификация, оплата и т. Д.)

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

 

Пять, заголовок SOAP

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

  2. Это позволяет расширять сообщения SOAP в зависимости от приложения.

  3. Блоки заголовка могут быть направлены на узлы SOAP, которые могут встречаться в пути сообщения от отправителя к конечному получателю.

 

Шесть, SOAP узел

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

 

Голова имеет три необязательных атрибута:

  1. субъект: определить, должен ли узел обрабатывать определенный заголовок

  2. mustUnderstand: если установлено значение «true», узел должен знать, как обрабатывать заголовок.

  3. relay: указывает, следует ли пересылать необработанные блоки заголовка.

 

Семь, протокол привязки

  1. Структура обмена сообщениями SOAP не зависит от базового протокола

  2. Привязка конкретного протокола точно определяет, как использовать данный протокол для передачи сообщений SOAP.

  3. Стандартные привязки протокола определены для обеспечения высокой степени взаимодействия между приложениями SOAP и инфраструктурой.

  4. Спецификация SOAP1,1 только связывает и кодирует стандартный протокол HTTP

  5. Привязка HTTP: Привязка протокола HTTP определяет правила использования SOAP через HTTP.

  6. SOAP: запрос / ответ естественным образом сопоставляется с моделью HTTP-запроса / ответа.

 

8. Пример привязки протокола-запроса

<! - [HTTP header] ->

POST /Temperature HTTP/1.1

Host: www.weather.com

Content-Type: text/xml

Content-Length: n

 <! - [Балансировка нагрузки XML] ->

<s:Envelope xmlns:s=“http://www.w3.org/2001/06/soap-envelope">

  <s:Body>

  … …

  </s:Body>

</s:Envelope>

<wsdl:binding name="InventoryServiceSoapBinding" type="InventoryService">

      <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>

      <wsdl:operation name="inquiryInventory">

         <soap:operation soapAction="http://abc.com/get"/>

         <wsdl:input name="inquiryInventoryRequest">

            <soap:body use="literal"/>

         </wsdl:input>

         <wsdl:output name="inquiryInventoryResponse">

            <soap:body use="literal"/>

         </wsdl:output>

      </wsdl:operation>

</wsdl:binding>


Девять, привязка WSDL и SOAP

  1. тег мыла: привязка имеет два атрибута

    1. стиль: «RPC» или «документ»

    2. транспорт: определяет протокол SOAP, который будет использоваться

    3. Для каждой операции необходимо определить соответствующую операцию SOAP. Кроме того, необходимо указать кодировку входных и выходных сообщений.

 

Десять, стиль сообщения SOAP

Два основных стиля сообщений SOAP

  1. Стиль документа: указывает, что тело содержит только документы XML, и отправитель и получатель должны согласовать формат.

  2. Стиль RPC: представление Основная часть содержит XML-представление вызова метода.

 

11. SOAP-сообщения в стиле документа

<Envelope xmlns:s=“http://www.w3.org/2001/06/soap-envelope”>

      <Body>

           <purchaseOrder xmlns:n=“urn:OrderService”>

             <from>

                 <person>Christopher Robin</person>

                 <dept>Accounting</dept>

             </from>

             <to>

                 <person>Pooh Bear</person>

                 <dept>Honey></dept>

             </to>

             <order>

                  <quantity>1</quantity>

                  <item>Pooh Stick</item>

             </order>

           </purchaseOrder>

     </Body>

</Envelope>

Двенадцать сообщений удаленного вызова: два типичных сообщения

13. SOAP-сообщения в стиле RPC

<! - Request ->

<Envelope xmlns:s=“http://www.w3.org/2001/06/soap-envelope”>

  <Body>

      <getQuote xmlns:n=“urn:QuoteService”>

           <symbol xsi:type=“xsd:string”>IBM</symbol>

      </getQuote>

  </Body>

</Envelope>

 <! - Ответ ->

<Envelope xmlns:s=http://www.w3.org/2001/06/soap-envelope>

  <Body>

      <getQuoteResponse xmnls:n=“urn:QuoteService”>

          <value xsi:type=“xsd:float”>98.06</value>

      </getQuoteResponse>

  </Body>

</Envelope>

14. Стиль сообщения SOAP

Существует два метода принятия решения о том, как сериализовать данные в тело: (указано в атрибуте use элемента <soap: body> в WSDL)

Литерал: определение архитектуры буквально определяет формат XML субъекта без двусмысленности.

Закодировано: Процессор SOAP должен пересмотреть различные правила кодирования SOAP во время выполнения, чтобы определить правильную сериализацию субъекта.

 

15. Резюме

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

  2. Легкая альтернатива на основе XML и существующих интернет-протоколов для сложной технологии распределенных объектов.

  3. Эта спецификация описывает, как использовать SOAP в вызовах HTTP и RPC.

 

Тестирование веб сервисов или как пользоваться SoapUI

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

О SoapUI

Итак, что же такое SoapUI? Это кроссплатформенное клиентское оконное приложение, написанное на языке Java. Использовать основной функционал приложения можно бесплатно. В платной версии программы, которая называется SoapUI Pro, вы сможете делать чуть больше, например, устанавливать плагины с помощью менеджера плагинов, проводить тесты драйверов данных, перехватывать трафик, оценивать покрытие ваших веб-сервисов тестами и создавать отчёты. Официальная страничка проекта находится здесь, скачать дистрибутив бесплатной версии программы можно здесь. Если бесплатной версии вам не хватает, вы можете скачать пробную версию SoapUI Pro здесь.

Если для разработки вы используете IDE IntelliJ, NetBeans или Eclipse, то вы можете интегрировать SoapUI прямо в IDE используя плагины. Как это сделать написано здесь. Я не буду останавливаться на этом варианте. Здесь я опишу лишь вариант использования SoapUI, как самостоятельного приложения. Установка на компьютер под управлением Windows проходит быстро и не вызывает вопросов, поэтому на этом этапе я тоже не буду заострять внимание.

Тестирование веб-сервиса

Прежде чем продолжить изучать программу SoapUI сделаем тестовый веб-сервис. Я сделаю это в Visual Studio, у моего сервиса будет только две функции GetSum1 и GetSum2, которые работают одинаково, но принимают и отдают результат по-разному.

using System;
using System.Collections.Generic;
using System.Data;
using System.Threading;
using System.Web;
using System.Web.Services;
 
namespace SoapUITester
{
   /// <summary>
   /// Веб-сервис для тестирования программы SoapUI.
   /// </summary>
   [WebService(Namespace = "http://www.proghouse.ru/SoapUITester")]
   [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
   [System.ComponentModel.ToolboxItem(false)]
   public class Service1 : System.Web.Services.WebService
   {
 
      [WebMethod]
      public int GetSum1(int a, int b, int? c)
      {
         //Сделаем задержку для отрицательных чисел
         if (a < 0 || b < 0 || (c.HasValue && c.Value < 0))
            Thread.Sleep(100);
         //Искуственно заложим здесь ошибку при вычислениях
         if (a == 5)
            return -1;
         return a + b + (c.HasValue ? c.Value : 0);
      }
 
      [WebMethod(EnableSession = true)]
      [System.Web.Services.Protocols.SoapDocumentMethodAttribute(ParameterStyle = System.Web.Services.Protocols.SoapParameterStyle.Bare)]
      public ContrAgInvoiceResponse GetSum2(ContrAgInvoiceRequest request)
      {
         //Сделаем задержку для всей функции
         Thread.Sleep(200);
         ContrAgInvoiceResponse response = new ContrAgInvoiceResponse();
         response.sessionID = Session.SessionID;
         response.sum = request.a + request.b + (request.c.HasValue ? request.c.Value : 0);
         return response;
      }
 
   }
 
   public class ContrAgInvoiceRequest
   {
      public int a;
      public int b;
      public int? c;
   }
 
   public class ContrAgInvoiceResponse
   {
      public string sessionID;
      public int sum;
   }
}

Теперь запустите программу SoapUI и создайте новый проект. Для этого в меню выберите пункт «File -> New SOAP Project». В появившемся окне задайте имя проекту и путь к WSDL. При включенной галочке «Create Requests» при создании проекта автоматически создадутся шаблоны для запросов к веб-сервису, эту галку мы оставим. Если установлена галка «Create TestSuite», то при создании проекта создадутся тесты. Нажмите кнопку «OK».

После этого мы увидим, что для нашего тестового веб-сервиса создались запросы, причём для версий протокола SOAP 1.1 и 1.2. Дважды щёлкните на запрос «Request 1» и справа откроется дочернее окошко «Request 1», в котором вы увидите сформированный запрос.

Чтобы теперь проверить, как работает наш тестовый веб-сервис, замените вопросительные знаки значениями и нажмите на зелёный треугольник (сверху слева в этом же дочернем окне), чтобы отправить запрос. Когда запрос выполнится, в правой части отобразится ответ сервера (на картинке веб-служба вернула число 7), а снизу слева время выполнения (на картинке 3 миллисекунды) и количество полученных байт (на картинке 358 байт).

Теперь вычислим сумму с отрицательным числом. Как видно на картинки, функция GetSum1 с отрицательными числами работает дольше. Это ожидаемый результат, т.к. в функции GetSum1 специально стоит задержка 100мс, если хотя бы одно из полученных чисел отрицательное.

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

Третий параметр у нас необязательный. Проверим, что будет, если мы его уберём из запроса. После выполнения мы увидим, что сумма посчиталась, ошибок нет.

Как видите, проверить работу веб-сервиса можно очень просто и быстро.

Тесты

Теперь попробуем создать тесты для сервиса. Сначала добавьте в проект набор тестов (TestSuite).

Затем в набор тестов добавьте тестовый случай (TestCase).

Теперь в новый тестовый случай можно добавить шаги для теста. Добавим тестовый запрос «Test Request».

В диалоге «New TestRequest» выбираем тестируемую функцию «GetSum1».

На следующем диалоге можно выбрать дополнительные утверждения, которые будут проверяться при проведении тестов: Add SOAP Response Assertion (добавляет утверждение, что ответ является SOAP-сообщением), Add Schema Assertion (добавляет утверждение, что ответ соответствует схеме), Add NOT SOAP Fault Assertion (добавляет утверждение, что ответ не является SOAP-ошибкой). Также здесь можно указать, нужно ли создать шаблон для необязательных элементов в запросе. Поставьте первую и третью галочку.

После добавления шага теста можно задать параметры и выполнить тест. Для выполнения теста также нажимаем зелёный треугольник.

Как видите после тестирования слева от названия шага «Test Request» отобразилась зелёная картинка-статус, сигнализирующая, что тест выполнен успешно. Теперь в первом параметре передайте строку и запустите тест. После тестирования вы можете увидеть, что картинка-статус поменяла цвет на красный, а на нижней левой панели отображается, что пошло не так. В нашем примере – это SOAP-ошибка «Not SOAP Fault — FAILED». Там же на закладке «Request Log» вы можете посмотреть, когда выполнялся тест, сколько по времени и сколько байт было возвращено.

Теперь сделаем тестирование диапазона значений. Будем подставлять в параметр «a» значения от 1 до 5 и проверять сумму. Для этого сначала нужно добавить свойство, которое будет хранить текущее значение параметра «a», например, в тестовый случай «TestCase 1». Для этого дважды щёлкните по нему на панели «Navigator». Затем в открывшемся дочернем окне «TestCase 1» откройте вкладку «Properties», щёлкните на кнопку с плюсом и задайте новому свойству имя «aValue» и значение 1.

Теперь переключитесь в тестовый запрос «Test Request» (дважды щёлкнув по нему на панели «Navigator») сотрите значение в параметре «a» и щёлкните по тому месту, где нужно будет вставить значение свойства, правой клавишей мышки и в меню выберите только что добавленный параметр «Get Data… -> TestCase: [TestCase 1] -> Property [aValue]».

После этого вместо статического значения параметра вы увидите текст ${#TestCase#aValue}. Можете теперь запустить тест и удостовериться, что при тестировании будет подставлена единица вместо строки ${#TestCase#aValue} и сумма получится равная 7.

После выполнения запроса вы можно посмотреть, что было передано веб-сервису, в частности, какое значение параметра «a» было передано на сервер, на закладке «Raw» (сырые данные). Здесь вы увидите HTTP-запрос полностью вместе с заголовочной частью. Аналогично можно посмотреть HTTP-ответ от веб-сервиса.

Кстати, для более удобного доступа к свойствам вы можете включить режим отображения свойств на панели навигатора (маленькая кнопка слева сверху на панели). Тогда свойства можно просматривать прямо на панели «Navigator». После этого дважды щёлкнув на свойство в навигаторе, вы можете поменять его значение.

Как видите из картинки, свойства могут быть заданы для проекта в целом, для отдельного набора тестов (TestSuite) или для отдельной тестовой ситуации (TestCase).

Теперь сделаем установку свойству «aValue» значения 1 в начале тестирования. Для этого откройте тестовый случай «TestCase 1», откройте вкладку «Setup Script» (скрипт инициализации вызывается перед выполнением тестового случая) и добавьте сюда следующий код:

log.info "Инициализация свойства aValue"
testRunner.testCase.setPropertyValue("aValue", "1")

Здесь же сразу можно проверить, как выполняется скрипт. Для этого нажмите на зелёный треугольник. Если при выполнении возникнут ошибки, то появится диалоговое окно с их описанием. В нашем случае всё отработало нормально. Откройте вкладку «script log», чтобы увидеть наше сообщение.

Здесь нужно сразу заметить, что все скрипты в SoapUI по умолчанию пишутся на языке Groovy, и в статье я буду использовать этот скрипт. Справку по языку можно получить здесь. По желанию вы можете использовать JavaScript для написания скриптов, тогда для правильной интерпретации ваших скриптов нужно установить в свойстве проекта «Script Language» значение «Javascript». В этом случае для интерпретации скриптов будет использоваться движок Rhino.

Также обратите внимание, что над каждым окошком для написания скрипта перечислены доступные глобальные переменные. На картинке сверху – это переменные log, testCase, context и testRunner.

Теперь после каждого шага «Test Request» нам нужно увеличивать значение свойства «aValue» на единицу. Чтобы это сделать, добавьте в тестовую ситуацию (TestCase) шаг «Groovy Script» — пункт контекстного меню «Add Step -> Groovy Script».

После добавления шага напишите следующий скрипт для изменения значения свойства:

Integer curValue = new Integer(testRunner.testCase.getPropertyValue( "aValue" ))
log.info "Текущее значение: " + curValue
curValue += 1
testRunner.testCase.setPropertyValue("aValue", curValue.toString())
log.info "Значение после изменения: " + curValue

Здесь вы сразу можете выполнить скрипт и увидеть на панели навигатора изменённое значение свойства «aValue», а на вкладке «Log Output» увидите наш лог.

Теперь попробуем циклично выполнять шаги «Test Requset» и «Groovy Script». Для того чтобы это сделать добавьте к скрипту следующие строчки:

if (curValue < 10)
   testRunner.gotoStepByName( "Test Request")

Как видите, цикл будет выполняться пока значение свойства «aValue» меньше 10. Теперь откройте тестовый случай «TestCase 1» и выполните его. Как видите на вкладке «TestCase Log», всего выполнилось 18 шагов (9 «Test Request» и 9 «Groovy Script»).

Теперь нужно отловить ошибку в вычислениях, которую мы специально заложили в веб-сервисе. Сервис должен вернуть -1, если первый параметр функции «GetSum1» равен 5. Для этого будем проверять результат работы функции. Чтобы добавить утверждение, которое будет проверять SoapUI, щёлкните по кнопке «Add an assertion to this item» (см. картинку), и в диалоге выбора утверждения выберите «Script Assertion».

И в диалоге «Script Assertion» пропишите скрипт проверки результата.

import com.eviware.soapui.support.XmlHolder
//Парсим запрос и ответ
def resp = new XmlHolder( messageExchange.responseContentAsXml )
def req = new XmlHolder( messageExchange.requestContentAsXml )
//Прописываем пространства имён
resp.namespaces["xmlns"] = "http://www.proghouse.ru/SoapUITester"
req.namespaces["soap1"] = "http://www.proghouse.ru/SoapUITester"
//Считываем результат из ответа
Integer result = new Integer(resp.getNodeValue('//xmlns:GetSum1Result'))
//Считываем параметры из запроса
Integer a = new Integer(req.getNodeValue('//soap1:a'))
Integer b = new Integer(req.getNodeValue('//soap1:b'))
Integer c = new Integer(req.getDomNode('//soap1:c') == null ? 0 : req.getNodeValue('//soap1:c'))
//Проверяем утверждение
assert result == a + b + c

Здесь же сразу можно проверить результат, выполнив скрипт. На картинке видно, что скрипт выполнился успешно – утверждение истинно.

Теперь поменяем в качестве эксперимента параметр «aValue» – установим значение 5 и выполним тест «Test Request». После выполнения вы увидите, что тест провален (красная иконка в навигаторе) и увидите, какое утверждение не выполнено. В нашем случае – это утверждение «Script Assertion».

Теперь выполним всю ситуацию «TestCase 1». После выполнения на вкладке «TestCase Log» мы видим, что тестирование прошло с ошибкой. Выполнение было прервано на шаге 9. Предыдущие шаги были выполнены без ошибок. Дважды щёлкнув на шаг 9 в логе, мы можем узнать, какой запрос был передан веб-сервису и что было возвращено (в нашем случае сумма посчиталась неправильно).

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

Нагрузочное тестирование

Чтобы проверить, выдерживает ли сервер требуемую нагрузку, или понять, какие функции выполняются медленно, мы можем провести нагрузочное тестирование. В нашем примере умышленно сделана большая задержка в функции «GetSum2». Давайте обнаружим эту задержку с помощью нагрузочного тестирования.

Сначала сделайте новую тестовую ситуацию «TestCase 2», добавьте в неё тестовый запрос «Test Request 1» для функции веб-сервиса «GetSum1» и тестовый запрос «Test Request 2» для функции «GetSum2». Вместо статических значений параметров поставьте следующий скрипт: ${=(int)(Math.random() * 100) — 50}. Так в качестве значений параметров будут устанавливаться отрицательные и положительные числа подобранные случайным образом. У вас должны получиться следующие SOAP-запросы:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:soap1="http://www.proghouse.ru/SoapUITester">
   <soap:Header/>
   <soap:Body>
      <soap1:GetSum1>
         <soap1:a>${=(int)(Math.random() * 100) - 50}</soap1:a>
         <soap1:b>${=(int)(Math.random() * 100) - 50}</soap1:b>
         <soap1:c>${=(int)(Math.random() * 100) - 50}</soap1:c>
      </soap1:GetSum1>
   </soap:Body>
</soap:Envelope>

для функции «GetSum1» и для функции «GetSum2»:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:soap1="http://www.proghouse.ru/SoapUITester">
   <soap:Header/>
   <soap:Body>
      <soap1:request>
         <soap1:a>${=(int)(Math.random() * 100) - 50}</soap1:a>
         <soap1:b>${=(int)(Math.random() * 100) - 50}</soap1:b>
         <soap1:c>${=(int)(Math.random() * 100) - 50}</soap1:c>
      </soap1:request>
   </soap:Body>
</soap:Envelope>

Теперь добавьте нагрузочный тест (пункт контекстного меню «New LoadTest»).

После добавления нагрузочного теста сразу всё готово к его запуску. Здесь вы можете задать количество потоков, стратегию выполнения и параметры для каждой стратегии (вы можете параллельно выполнять несколько тестов, используя разную стратегию). Выполните тест.

После выполнения в таблице вы увидите минимальное и максимальное время выполнения теста, среднее значение, количество ошибок и пр. На вкладке «LoadTest Log» будет указано время начала и окончания теста. Также вы можете посмотреть статистику и историю на графиках.

По таблице вы можете заметить, что тест «Test Request 2» выполняется дольше. В среднем 203,55 мс, а тест «Test Request 1» выполняется быстрее примерно в 2 раза. Вот мы и обнаружили, что в функции «GetSum2» есть задержка при выполнении.

Тестирование клиента

Теперь давайте попробуем создать имитацию веб-сервиса с помощью программы SoapUI. Это может пригодиться для тестирования клиента веб-сервиса. Ведь с помощью такого имитатора веб-сервиса вы сможете протестировать все возможные ситуации на клиенте.

Чтобы создать веб-сервис, щёлкните по SOAP-интерфейсу и в контекстном меню выберите пункт «Generate SOAP Mock Service».

В поднявшемся диалоге вы можете выбрать функции, для которых нужно создать операции сервиса, путь к сервису и порт. Нажмите «OK».

После того как сервис создан, дважды щёлкните по запросу, который хотите поправить, например, по «Response 1» и задайте параметр, который должна вернуть функция GetSum1. Вы можете здесь задать статическое значение, которое будет получать клиент или вычислять его в зависимости от входных параметров. Также здесь вы можете задать ответ-ошибку и протестировать, как клиент будет обрабатывать сообщение с ошибкой.

Мы здесь сделаем расчёт суммы и возврат результата с помощью скрипта. Откройте вкладку «Script» и напишите следующий код:

import com.eviware.soapui.support.XmlHolder
//Парсим запрос и ответ
def req = new XmlHolder( mockRequest.getContentElement() )
//Прописываем пространства имён
req.namespaces["soap1"] = "http://www.proghouse.ru/SoapUITester"
//Считываем параметры из запроса
Integer a = new Integer(req.getNodeValue('//soap1:a'))
Integer b = new Integer(req.getNodeValue('//soap1:b'))
Integer c = new Integer(req.getDomNode('//soap1:c') == null ? 0 : req.getNodeValue('//soap1:c'))
//Сохраняем значение в свойстве "result"
context.setProperty("result", a + b + c)

После этого в SOAP-ответе вместо вопроса можно подставить следующую строку: ${=result}. У вас должен получиться такой ответ:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://www.proghouse.ru/SoapUITester">
   <soapenv:Header/>
   <soapenv:Body>
      <soap:GetSum1Response>
         <soap:GetSum1Result>${=result}</soap:GetSum1Result>
      </soap:GetSum1Response>
   </soapenv:Body>
</soapenv:Envelope>

Вот так это выглядит в программе:

Теперь, можете запустить сервис. Для этого переключитесь в навигаторе на сервис, у меня это «Service1Soap MockService» и щёлкните по зелёному треугольнику. После запуска сверху будет двигаться бегунок показывающий, что сервис работает.

Теперь можно тестировать клиента. Я для примера сделал консольное приложение в Visual Studio, добавил в проект ссылку, указав ссылку на WSDL (WSDL можно получить, щёлкнув по кнопке с изображением зелёной фигуры, на картинке сверху она обведена зелёным кружком). Далее можно вызывать функцию сервиса «GetSum1». Вот код консольного приложения:

using SoapUITesterClient.localhost;
using System;
using System.Collections.Generic;
using System.Text; 
 
namespace SoapUITesterClient
{
   class Program
   {
      static void Main(string[] args)
      {
         Service1 service = new Service1();
         Console.WriteLine(service.GetSum1(1, 2, 4));
      }
   }
}

После выполнения приведённого кода программы в консоль будет выведен результат 7.

Также при создании сервиса вы можете тестировать его здесь же прямо из программы SoapUI.

Заключение

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

 

XML-мыло

  • SOAP означает S реализация O объект A ccess П протокол
  • SOAP — это протокол связи приложений
  • SOAP — это формат для отправки и получения сообщений
  • SOAP не зависит от платформы
  • SOAP основан на XML
  • SOAP — это рекомендация W3C

Почему именно SOAP?

Для веб-приложений важно иметь возможность обмениваться данными через Интернет.

Лучший способ связи между приложениями — через HTTP, потому что HTTP поддерживается всеми интернет-браузерами и серверы. SOAP был создан для этого.

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

Строительные блоки SOAP

Сообщение SOAP — это обычный XML-документ, содержащий следующие элементы:

  • Элемент конверта, который идентифицирует XML-документ как сообщение SOAP
  • Элемент заголовка, содержащий информацию заголовка
  • Элемент Body, содержащий информацию о вызове и ответе
  • Элемент неисправности, содержащий ошибки и информацию о состоянии

Все перечисленные выше элементы объявлены в пространстве имен по умолчанию для конверта SOAP:

http: // www.w3.org/2003/05/soap-envelope/

, а пространство имен по умолчанию для кодировки SOAP и типов данных:

http://www.w3.org/2003/05/soap-encoding

Правила синтаксиса

Вот некоторые важные правила синтаксиса:

  • Сообщение SOAP ДОЛЖНО быть закодировано с использованием XML
  • Сообщение SOAP ДОЛЖНО использовать пространство имен SOAP Envelope
  • Сообщение SOAP НЕ ДОЛЖНО содержать ссылку на DTD.
  • Сообщение SOAP НЕ ДОЛЖНО содержать инструкций по обработке XML.

Скелет сообщения SOAP

xmlns: soap = «http: // www.w3.org/2003/05/soap-envelope/ «
soap: encodingStyle =» http://www.w3.org/2003/05/soap-encoding «>


…


…
<мыло: неисправность>
…

Элемент конверта SOAP

Требуемый элемент конверта SOAP является корневым элементом сообщения SOAP. Этот элемент определяет XML-документ как сообщение SOAP.

Пример

xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/ мыло-кодирование «>
…
Информация о сообщении находится здесь
…

Пространство имен xmlns: soap

Обратите внимание на пространство имен xmlns: soap в приведенном выше примере. Он всегда должен иметь значение: «http://www.w3.org/2003/05/soap-envelope/».

Пространство имен определяет конверт как конверт SOAP.

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

Атрибут encodingStyle

Атрибут encodingStyle используется для определения типов данных, используемых в документ. Этот атрибут может появиться в любом элементе SOAP и применяется к его содержимому и всем дочерним элементам.

Сообщение SOAP не имеет кодировки по умолчанию.

Синтаксис
Пример

xmlns: soap = «http: // www.w3.org/2003/05/soap-envelope/ «Мыло
: encodingStyle =» http://www.w3.org/2003/05/soap-encoding «>
…
Информация о сообщении находится здесь
…

Элемент заголовка SOAP

Необязательный элемент заголовка SOAP содержит специфичную для приложения информацию (например, аутентификацию, оплату и т. Д.) О сообщении SOAP.

Если элемент Header присутствует, он должен быть первым дочерним элементом элемента Envelope.

Примечание: Все непосредственные дочерние элементы элемента Header должны быть квалифицированы пространством имен.

xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/ soap-encoding «>


мыло: mustUnderstand = «1»> 234


…
…

Пример выше содержит заголовок с элементом Trans, mustUnderstand. атрибут со значением 1 и значением 234.

SOAP определяет три атрибута в пространстве имен по умолчанию. Эти атрибуты: mustUnderstand, актер и encodingStyle.

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

Атрибут mustUnderstand

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

Если вы добавите mustUnderstand = «1» к дочернему элементу элемента Header, это означает, что получатель, обрабатывающий заголовок, должен распознать элемент.Если получатель не распознает элемент, который не удастся при обработке заголовка.

Синтаксис

мыло: mustUnderstand = «0 | 1»

Пример

xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/ soap-encoding «>


мыло: mustUnderstand = «1»> 234


…
…

Актер Атрибут

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

Атрибут актора SOAP используется для адресации элемента заголовка определенной конечной точке.

Синтаксис

Пример

xmlns: soap = «http: // www.w3.org/2003/05/soap-envelope/ «
soap: encodingStyle =» http://www.w3.org/2003/05/soap-encoding «>


мыло: актер = «https://www.w3schools.com/code/»> 234


…
…

Атрибут encodingStyle

Атрибут encodingStyle используется для определения типов данных, используемых в документ.Этот атрибут может появиться в любом элементе SOAP, и он будет применяться к этому содержимое элемента и все дочерние элементы.

Сообщение SOAP не имеет кодировки по умолчанию.

Синтаксис

Элемент тела SOAP

Требуемый элемент тела SOAP содержит фактическое сообщение SOAP, предназначенное для конечной конечной точки сообщения.

Непосредственные дочерние элементы элемента SOAP Body могут быть квалифицированы пространством имен.

Пример

xmlns: soap = «http: // www.w3.org/2003/05/soap-envelope/ «
soap: encodingStyle =» http://www.w3.org/2003/05/soap-encoding «>



Яблоки

В приведенном выше примере запрашивается цена на яблоки. Обратите внимание, что m: GetPrice и Элементы Item выше относятся к конкретным элементам приложения.Они не являются частью пространства имен SOAP.

Ответ SOAP может выглядеть примерно так:

xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http://www.w3.org/2003/05/ мыло-кодировка «>

<мыло: Тело>

1,90


Элемент ошибки SOAP

Необязательный элемент SOAP Fault используется для обозначения ошибки. Сообщения.

Элемент SOAP Fault содержит ошибки и информация о состоянии для сообщения SOAP.

Если присутствует элемент Fault, он должен отображаться как дочерний элемент элемента Body. Элемент Fault может появляться в сообщении SOAP только один раз.

Элемент SOAP Fault имеет следующие подэлементы:

Подэлемент Описание
<код неисправности> Код для определения неисправности
Объяснение неисправности, понятное человеку
<фактор неисправности> Информация о виновнике неисправности
<подробно>

Содержит информацию об ошибках приложения, связанных с Кузовной элемент

Коды ошибок SOAP

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

Ошибка Описание
Несоответствие версии Обнаружено недопустимое пространство имен для элемента конверта SOAP
Должен понять Непосредственный дочерний элемент элемента Header с атрибутом mustUnderstand, установленным на «1», был не понял
Клиент Сообщение было неправильно сформировано или содержало неверную информацию
Сервер Возникла проблема с сервером, поэтому сообщение не может быть продолжено

Протокол HTTP

HTTP обменивается данными через TCP / IP.Клиент HTTP подключается к серверу HTTP с помощью TCP. После установления соединения клиент может отправить на сервер сообщение HTTP-запроса:

POST / item HTTP / 1.1
Хост: 189.123.255.239
Content-Type: text / plain
Content-Length: 200

Затем сервер обрабатывает запрос и отправляет ответ HTTP клиенту. Ответ содержит код статуса, который указывает статус запроса:

200 OK
Content-Type: text / plain
Content-Length: 200

В приведенном выше примере сервер вернул код состояния 200.Это стандартный код успеха для HTTP.

Если сервер не смог декодировать запрос, он мог бы вернуть что-то вроде этого:

400 неверный запрос
Content-Length: 0

Привязка SOAP

Спецификация SOAP определяет структуру сообщений SOAP, а не то, как они обмениваются. Этот пробел заполняется так называемыми «привязками SOAP». МЫЛО привязки — это механизмы, которые позволяют эффективно обмениваться сообщениями SOAP. с использованием транспортного протокола.

Большинство реализаций SOAP предоставляют привязки для общих транспортных протоколов, например HTTP или SMTP.

HTTP является синхронным и широко используется. HTTP-запрос SOAP указывает по крайней мере два заголовка HTTP: Content-Type и Content-Length.

SMTP является асинхронным и используется в крайних случаях или в особых случаях.

Java-реализации SOAP обычно предоставляют конкретную привязку для JMS. (Система обмена сообщениями Java) протокол.

Content-Type

Заголовок Content-Type для запроса и ответа SOAP определяет тип MIME для сообщения и кодировка символов (необязательно), используемая для тела XML запроса или ответа.

Синтаксис

Тип содержимого: MIMEType; charset = кодировка символов

Пример

POST / item HTTP / 1.1
Content-Type: application / soap + xml; charset = utf-8

Длина содержимого

Заголовок Content-Length для запроса и ответа SOAP определяет количество байтов в теле запроса или ответа.

Синтаксис
Пример

POST / item HTTP / 1.1
Content-Type: application / soap + xml; charset = utf-8
Content-Length: 250

Пример SOAP

В приведенном ниже примере запрос GetStockPrice отправляется на сервер.В запросе есть параметр StockName, и параметр Price, который будет возвращен в ответе. Пространство имен для функции определено в «http://www.example.org/stock».

Запрос SOAP:

POST / InStock HTTP / 1.1
Хост: www.example.org
Content-Type: приложение / мыло + xml; charset = utf-8
Content-Length: nnn

xmlns: soap = «http://www.w3.org/2003/05/soap-envelope/»
soap: encodingStyle = «http: // www.w3.org/2003/05/soap-encoding «>



IBM

Ответ SOAP:

HTTP / 1.1 200 ОК
Content-Type: приложение / мыло + xml; charset = utf-8
Content-Length: nnn

xmlns: soap = «http: // www.w3.org/2003/05/soap-envelope/ «
soap: encodingStyle =» http://www.w3.org/2003/05/soap-encoding «>



34,5



SOAP vs REST API: что подходит именно вам?

Извечный вопрос: в чем разница между SOAP и REST API и какой из них подходит для моего проекта?

Тот факт, что наше имя — SoapUI, не означает, что мы также не знаем, о чем говорим, когда дело доходит до объяснения веб-сервисов и API RESTful.

Итак, если вы ищете ресурс, который даст вам ответ на этот извечный вопрос, вы попали в нужное место. Мы также рассмотрим пример кода, а также вызовы и критические замечания по каждому выбору.

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

Начните здесь:

SOAP против REST

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

Серверная часть веб-API — это программный интерфейс для определенной системы сообщений «запрос-ответ», который обычно называется веб-службой. Существует несколько моделей проектирования веб-сервисов, но две наиболее распространенные — это SOAP и REST.

SOAP обеспечивает следующие преимущества по сравнению с REST:

  • Независимость от языка, платформы и транспорта (REST требует использования HTTP)
  • Хорошо работает в распределенных корпоративных средах (REST предполагает прямую связь точка-точка)
  • Стандартизированный
  • Обеспечивает значительную расширяемость перед сборкой в ​​форме стандартов WS *
  • Встроенная обработка ошибок
  • Автоматизация при использовании некоторых языковых продуктов

REST по большей части проще в использовании и более гибок.Он имеет следующие преимущества по сравнению с SOAP:

  • Использует простые для понимания стандарты, такие как swagger и OpenAPI Specification 3.0
  • Меньшая кривая обучения
  • Эффективный (SOAP использует XML для всех сообщений, REST в основном использует меньшие форматы сообщений, такие как JSON)
  • Fast (не требует обширной обработки)
  • Ближе к другим веб-технологиям в философии дизайна

Как сказано в одном руководстве по REST API: SOAP похож на конверт, а REST — это просто открытка.

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

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

Это просто версия TL; DR. Продолжайте читать ниже, чтобы подробнее узнать об этих двух форматах. Или посмотрите инфографику SOAP vs REST, если это вам больше подходит.

SOAP

SOAP — простой протокол доступа к объектам — вероятно, наиболее известная из двух моделей.

SOAP в значительной степени полагается на XML и вместе со схемами определяет структуру обмена сообщениями с очень строгим контролем типов.

Каждая операция, предоставляемая службой, явно определяется вместе со структурой XML запроса и ответа для этой операции.

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

Все это кодифицировано на языке WSDL — Web Service Description (или Definition, в более поздних версиях).WSDL часто называют контрактом между поставщиком и потребителем услуги. С точки зрения программирования WSDL можно рассматривать как сигнатуру метода для веб-службы.

SoapUI с открытым исходным кодом

  • Поддержка тестирования SOAP и REST API.
  • Простое переключение между средами.
  • Подробная история тестов и отчет о сравнении тестов.

SoapUI Pro

  • Поддержка тестирования API SOAP, REST и GraphQL.
  • Простое переключение между средами.
  • Подробная история тестов и отчет о сравнении тестов.

Пример:

Пример обмена сообщениями выглядит следующим образом.

Запрос от клиента:

POST http://www.stgregorioschurchdc.org/cgi/websvccal.cgi HTTP / 1.1
Принятие кодировки: gzip, deflate
Тип содержимого: текст / xml; кодировка = UTF-8
SOAPAction: "http://www.stgregorioschurchdc.org/Calendar#easter_date"
Длина содержимого: 479
Хост: www.stgregorioschurchdc.org
Подключение: Keep-Alive
Пользовательский агент: Apache-HttpClient / 4.1.1 (java 1.5)





 2014 г.

Ответ службы:

HTTP / 1.1 200 ОК
Дата: пт, 22 ноября 2013 г., 21:09:44 GMT
Сервер: Apache / 2.0.52 (Red Hat)
SOAPServer: SOAP :: Lite / Perl / 0.52
Длина содержимого: 566
Подключение: закрыть
Тип содержимого: текст / xml; charset = utf-8




 2014/04/20

Из этого примера мы видим, что сообщение было отправлено по HTTP.SOAP фактически не зависит от основного транспортного протокола и может быть отправлен практически по любому протоколу, например HTTP, SMTP, TCP или JMS.

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

Содержит два обязательных элемента: заголовок и тело. Остальные элементы в этом сообщении описаны WSDL.

Сопутствующий WSDL, который определяет вышеуказанный сервис, выглядит следующим образом (детали не важны, но весь документ показан здесь для полноты):


<определения xmlns: tns = "http://www.stgregorioschurchdc.org/Calendar"
xmlns: soap = "http://schemas.xmlsoap.org/wsdl/soap/"
xmlns: xsd = "http://www.w3.org/2001/XMLSchema"
xmlns = "http://schemas.xmlsoap.org/wsdl/"
name = "Календарь" targetNamespace = "http://www.stgregorioschurchdc.org/Calendar">













<мыло: привязка транспорта = "http: // схемы.xmlsoap.org/soap/http "/>


<ввод>


<выход>

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

Попробуйте пример проекта SOAP в SoapUI

WSDL

WSDL определяет все аспекты сообщения SOAP. Он даже может определять, разрешено ли любому элементу или атрибуту появляться несколько раз, если он является обязательным или необязательным, и даже может диктовать определенный порядок, в котором элементы должны появляться.

Распространенное заблуждение, что WSDL — это требование для службы SOAP.

Протокол SOAP

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

С другой стороны, если разработчика просят взаимодействовать с существующей веб-службой SOAP, ему нужно предоставить только WSDL, и есть инструменты, которые выполняют обнаружение служб — генерируют заглушки методов с соответствующими параметрами практически на любом языке из этого WSDL.

Многие инструменты тестирования на рынке работают одинаково — тестировщик предоставляет URL-адрес WSDL, а инструменты генерируют все вызовы с примерными параметрами для всех доступных методов.

Критика SOAP

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

Помните, WSDL — это договор между вами (поставщиком услуги) и каждым из ваших клиентов (потребителей услуги).

Изменения WSDL также означают изменения клиента.

Если вы хотите внести изменения в свой API, даже такие небольшие, как добавление необязательного параметра, WSDL должен измениться.И изменения WSDL также означают изменения клиентов — все ваши потребители должны перекомпилировать свое клиентское приложение с этим новым WSDL.

Это небольшое изменение значительно увеличивает нагрузку на команды разработчиков (по обе стороны коммуникации), а также на команды тестирования. По этой причине WSDL рассматривается как привязка к версии, и большинство провайдеров очень сопротивляются обновлению своего API.

Более того, хотя SOAP предлагает некоторую интересную гибкость, такую ​​как возможность передачи по любому транспортному протоколу, на самом деле никто не воспользовался большинством из них.

Благодаря развитию Интернета все, что имеет значение, работает через HTTP.

Есть новые достижения, но большинству из них мешает то, что маршрутизаторы инфраструктуры отказываются маршрутизировать нестандартный HTTP-трафик. Только подумайте: сколько времени мир пытается перейти на IPv6?

Определенно существует потребность в более легкой и гибкой модели [чем SOAP].

В любой ситуации, когда размер передаваемого сообщения не имеет значения или когда вы контролируете все от начала до конца, протокол SOAP почти всегда является лучшим ответом.

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

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

ОТДЫХ

REST — REpresentational State Transfer — быстро становится предпочтительной моделью проектирования для общедоступных API (вы можете узнать больше о REST и о том, как протестировать эти API, в этой электронной книге REST 101: Руководство для начинающих по использованию и тестированию RESTful API).

REST расшифровывается как передача репрезентативного состояния. Это стиль архитектуры программного обеспечения, основанный на протоколе связи без сохранения состояния, чаще всего HTTP. REST структурирует данные в XML, YAML или любом другом машиночитаемом формате, но обычно наиболее широко используется JSON. REST следует парадигме объектно-ориентированного программирования существительного-глагола. REST сильно зависит от данных по сравнению с SOAP, который сильно зависит от функций. Вы можете видеть, что люди называют их RESTful API или веб-сервисами RESTful.Они означают одно и то же и могут быть взаимозаменяемыми.

Не существует стандарта для формата описания служб REST (вы можете импортировать службу REST в SoapUI с помощью файлов WADL). ReadyAPI поддерживает форматы OpenAPI, Swagger и RAML.

Основные HTTP-запросы REST: POST, GET, PUT и DELETE. SoapUI также поддерживает запросы HEAD, OPTIONS, TRACE и PATCH. Давайте посмотрим на пример из Swagger Pet Store API:

  • Отправка запроса GET в / pet / {petId} приведет к извлечению домашних животных с указанным идентификатором из базы данных.
  • Отправка POST-запроса на / pet / {petId} / uploadImage добавит новое изображение питомца.
  • Отправка запроса PUT в / pet / {petId} приведет к обновлению атрибутов существующего питомца, идентифицированного указанным идентификатором.
  • При отправке запроса DELETE к / pet / {petId} будет удалено указанное домашнее животное.

Итак, вкратце, вот что соответствует каждому из этих типов запросов:

ПОЛУЧИТЬ

Чтение или получение данных

ПОСТ

Добавить новые данные

PUT

Обновить уже существующие данные

УДАЛИТЬ

Удалить данные

Чтобы узнать больше о запросах REST и о том, как их выполнять в SoapUI, посетите нашу страницу Работа с запросами REST.

Пример:

Пример обмена сообщениями может содержать всего лишь это —

Запрос: 

ПОЛУЧИТЬ http://www.catechizeme.com/catechisms/catechism_for_young_children/daily_question.js HTTP / 1.1
Принятие кодировки: gzip, deflate
Хост: www.catechizeme.com
Подключение: Keep-Alive
Пользовательский агент: Apache-HttpClient / 4.1.1 (java 1.5)

Ответ: 

HTTP / 1.1 200 ОК
Дата: пт, 22 ноября 2013 г., 22:32:22 GMT
Сервер: Apache
X-Powered-By: Phusion Passenger (mod_rails / mod_rack) 3.0,17
ETag: "b8a7ef8b4b282a70d1b64ea5e79072df"
X-время выполнения: 13
Cache-Control: частный, max-age = 0, необходимо перепроверить
Длина содержимого: 209
Статус: 200
Keep-Alive: тайм-аут = 2, максимум = 100
Подключение: Keep-Alive
Content-Type: js; charset = utf-8
{
"ссылка": "катехизисы \ / катехизис_для_молодых_детей \ / вопросы \ / 36",
«катехизис»: «Катехизис для детей младшего возраста»,
"a": "Первородный грех.",
«позиция»: 36,
«q»: «Как называется та греховная природа, которую мы унаследовали от Адама?»
}

Как уже ожидалось, это сообщение было отправлено по HTTP с использованием команды GET.

Также обратите внимание, что URI, который также должен был быть включен в запрос SOAP, но там он не имел значения, здесь фактически принимает значение. Тело сообщения значительно меньше, в этом примере его фактически нет.

Служба REST также имеет схему на так называемом WADL — языке описания веб-приложений. WADL для вышеуказанного вызова будет выглядеть так:










<запрос />

<представление mediaType = "json" element = "data" />
<представление mediaType = "js; charset = utf-8" element = "data" />

WADL использует синтаксис XML для описания метаданных и доступных действий.Он также может быть таким же строгим, как WSDL: определение типов, необязательных параметров и т. Д.

Попробуйте пример проекта REST в SoapUI

WADL

WADL не имеет никакого механизма для представления самих данных, которые должны быть отправлены по URI. Это означает, что WADL может документировать только половину информации, необходимой для взаимодействия со службой.

Возьмем, к примеру, параметр CATECHISM_NAME в приведенном выше примере.WADL только сообщает вам, где в URI параметр принадлежит, и что это должна быть строка.

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

WADL не является обязательным.

Далее WADL полностью необязателен; на самом деле, WADL вообще поставляется довольно редко! В связи с характером службы, для того, чтобы ее можно было эффективно использовать, вам почти наверняка потребуется дополнительная документация.

Критика REST

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

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

Пожалуй, самым большим недостатком является WADL — необязательный и не имеющий некоторой необходимой информации. Чтобы устранить этот недостаток, на рынке доступно несколько фреймворков, которые помогают документировать и создавать RESTful API, например Swagger, RAML или JSON-home.Swagger был подарен Open API Iniative и теперь называется OpenAPI (OAS). Перейдите на Swagger.io, где вы можете узнать больше об этом стандарте, спецификации и о роли инструментов Swagger.

Никто не знает API лучше, чем SmartBear. Узнайте, что наша Pro-версия SoapUI может сделать для улучшения вашего тестирования.

Читать дальше:

SOAP vs REST Инфографика
Тестирование API 101
Разрыв между целями и реальностью при тестировании

Какая совок на мыло? | Исследуйте | Интересные мероприятия и забавные факты

Вероятно, вы слышите слова «Вымойтесь и используйте много мыла!» девятьсот раз в день.Но почему мыло так важно для мытья посуды? Как именно он так хорошо избавляется от микробов и грязи? Как это сделано? И как давно это было? Читайте дальше, чтобы узнать все ответы!

Грязь на мыло

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

Из чего традиционно делают мыло?

Форма, заполненная мылом, готовым к затвердеванию.

Мыло можно сделать двумя способами: горячим и холодным. В методе холодного процесса, который популярен для изготовления мыла вручную, они берут жирных кислот (оливковое масло, конопляное масло или говяжий жир) и смешивают их с щелоком . Собрав нужное количество каждого из них, вы получите химическую реакцию, называемую омыление , и смесь станет мылом.Есть также веганского (сделанного без использования продуктов животного происхождения) мыла, изготовленного с использованием растительных масел вместо животных жиров.

Как давно существует мыло?

Мыло существует уже давно. На самом деле это может быть одна из первых вещей, которые люди придумали для изготовления. Одна из теорий состоит в том, что люди на самом деле узнали, как делать мыло, случайно. Легенда гласит, что животный жир капал с мяса, которое готовилось на открытом огне. Этот жир стекает в пепел костра.Жир и пепел соединились, чтобы создать первое мыло!

Как действует мыло?

Некоторые думают, что мыло уничтожает грязь и другие вредные вещества. Это не совсем так. Мыло на самом деле действует, реагируя с маслами на вашей коже и позволяя воде смывать их. Понимаете, обычно масло и вода никогда не смешиваются. Если вы попытаетесь объединить их, они фактически разделятся и останутся отдельно.

Молекулы мыла имеют два разных конца.Один конец гидрофильный : этот конец притягивается к воде. Другой конец — гидрофобный : он боится воды и пытается уйти от нее. Когда вы моетесь с мылом, гидрофобные части мыла разделяют масло на более мелкие капли, которые затем могут улетучиваться в воде, которую вы используете для полоскания! И вуаля! Вы безупречно чисты!

Все очищающие средства мылом?

Имейте в виду, что «мыло» относится к продукту определенной химической реакции.Есть много продуктов, которые можно назвать мылом, но это не так. Например, «моющее средство» похоже на мыло и выполняет многие из тех же функций. Основное отличие в том, что он по-разному реагирует с минералами в воде. Он отлично подходит для стирки одежды, но его нельзя запачкать в волосах! Всегда полезно знать, какие вещества вы используете и для чего именно они лучше всего подходят.

Что такое глицерин и почему он в вашем мыле?

Независимо от того, сколько вы исследуете свои продукты личной гигиены, могут быть ингредиенты, которые иногда заставляют вас чесать голову.Слово глицерин может показаться устрашающим, но, как вы обнаружите, когда вы заметите ингредиент на куске мыла, вы почувствуете себя комфортно, используя его.

Несколько лет назад моя дочь получила научный набор, содержащий небольшую бутылку глицерина, как часть эксперимента. Она сразу спросила: «Что такое глицерин?» и мне пришлось признаться, что я не был уверен, хотя это действительно вызвало мысленный образ взрывчатки. Решили вместе поискать. В дополнение к уроку истории изобретения динамита мы обнаружили, что на самом деле это очень часто используемый ингредиент в продуктах личной гигиены и даже в продуктах питания.

Что такое глицерин?

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

Откуда берется глицерин?

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

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

Как обрабатывается глицерин для использования в продуктах?

Нет ничего нового в глицерине как ингредиенте средств личной гигиены. Он был частью процесса мыловарения с 19 века. Когда мыло производится с использованием животных жиров или растительных масел, в результате расщепления этих жиров и масел образуется глицерин. Это происходит в процессе омыления, когда жирные кислоты объединяются с сильной щелочью.

Чтобы получить высокочистый ингредиент, безопасный для использования в пищевых продуктах, глицерин проходит процесс отбеливания углем.Глицерин также можно перегонять, чтобы увеличить его концентрацию.

Для чего нужен глицерин в мыльных продуктах?

Глицерин используется в качестве увлажнителя в мыльных продуктах. Другими словами, глицерин помогает гарантировать, что ваша кожа будет поддерживать собственную влажность, чтобы защитить ее от повреждений, вызванных сухостью. Увлажнители, такие как глицерин, не создают барьер, а позволяют коже дышать.

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

Выбор продуктов, с которыми вам комфортно

Когда вы видите глицерин, указанный в составе вашего мыла как натуральный ингредиент, вы можете быть уверены в своем выборе. Помимо того, что глицерин является натуральным, он включен в список ингредиентов Управления по контролю за продуктами и лекарствами, которые в целом признаны безопасными, а рабочая группа по окружающей среде перечисляет глицерин с рейтингом 1-2, что означает, что он не считается токсином окружающей среды.

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

Хотите узнать больше об ингредиентах, которые входят в состав ваших натуральных средств личной гигиены? Подпишитесь на доску Ingredients from Nature от @tomsofmaine на Pinterest!

Источники изображения: Unsplash | Unsplash | Шер Варкентин

Взгляды и мнения, выраженные в любом гостевом посте на нашем сайте, принадлежат гостевому автору и не обязательно отражают мнения и взгляды Tom’s of Maine.

Какое мыло лучше? — Департамент здравоохранения Миннесоты

Антибактериальное мыло или обычное мыло: что лучше?

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

Способствует ли антибактериальное мыло устойчивости к антибиотикам?

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

Обычное мыло:

  • Рекомендовано для немедицинского использования
  • Легко найти в магазинах — читайте этикетку!
  • Обычно дешевле, чем антибактериальное мыло
  • Самым важным этапом при мытье рук является вытирание рук

Мыло антибактериальное:

  • Не требуется на предприятиях или в большинстве домов (кроме случаев, когда это предписано вашим лечащим врачом)
  • Убивает микробы на руках или теле не более эффективно, чем обычное мыло
  • Необходимо оставить на руках примерно на две минуты для воздействия на бактерии

Жидкое мыло или кусковое мыло?

Жидкое мыло:

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

Кусковое мыло:

  • На кусковом мыле могут расти микробы и легко передаваться от одного человека к другому
  • Кусковое мыло можно использовать в домашнем хозяйстве, если ни у кого нет кожных инфекций
  • Кусковое мыло нельзя использовать в общественных местах

Другой способ мыть руки: Дезинфицирующее средство для рук

  • Вымойте руки водой с мылом, если они заметно загрязнены.Если мыло и вода недоступны, используйте дезинфицирующее средство для рук на спиртовой основе (салфетки или гель).
  • Работники пищевых продуктов в ресторанах, школах, гастрономах и продуктовых магазинах должны мыть руки с мылом перед нанесением дезинфицирующих средств для рук. [Правила Минна, гл. 4626.0070 — 4626.0085]

Артикул:

  • Влияние антибактериальных очистителей для рук на уничтожение микробов на руках
    Гарвардская медицинская школа
  • Антибактериальное мыло? Вы можете пропустить это — используйте обычное мыло и воду, FDA
    По данным У.S. FDA (Управление по санитарному надзору за качеством пищевых продуктов и медикаментов), недостаточно научных данных, чтобы показать, что антибактериальное мыло, отпускаемое без рецепта, лучше предотвращает болезни, чем мытье простым мылом и водой.
  • Антибактериальные товары для дома: повод для беспокойства
    CDC: Новые инфекционные заболевания
  • Станьте умнее: знайте, когда работают антибиотики
    CDC: не было доказано, что продукты, содержащие антибактериальные препараты, предотвращают распространение инфекции лучше, чем продукты, не содержащие антибактериальных химикатов.
  • Мытье рук — Информационный бюллетень Пищевого кодекса Миннесоты (PDF)
    Информационный бюллетень «Безопасная еда — это хороший бизнес» из Продовольственного кодекса Миннесоты.
  • История регулирования и свойства потребительских антисептиков
    В 2005 году консультативная группа FDA рассмотрела вопрос об эффективности антибактериальных продуктов и в подавляющем большинстве пришла к выводу, что нет никаких доказательств того, что антибактериальное мыло более эффективно, чем обычное мыло, для предотвращения инфекции.
  • Обзор литературы журнала клинических инфекционных болезней
    В обзоре литературы, опубликованном в журнале Clinical Infectious Disease Journal, сделан вывод о том, что антибактериальное мыло не дает преимуществ, превосходящих обычное мыло, для в целом здоровых людей, живущих в сообществе. (Clin Infect Dis. 1 сентября 2007; 45 Приложение 2: S137-47)
  • Руководство APIC по мытью и антисептике рук в медицинских учреждениях
    Американский журнал инфекционного контроля, Ассоциация профессионалов в области инфекционного контроля и эпидемиологии
    (AJIC.1995 23: 251-269)

Какое дезинфицирующее средство для рук или мыло и вода лучше?

venusphoto / iStock / Thinkstock

Если вы хотите быстро продезинфицировать руки, вы можете достать бутылку дезинфицирующего средства для рук. Но насколько эффективно дезинфицирующее средство для рук по сравнению с мытьем рук водой с мылом?

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

Если вы решите использовать дезинфицирующее средство для рук, используйте его с содержанием спирта не менее 60% и следуйте приведенным ниже рекомендациям CDC.

Дезинфицирующее средство для рук, инструкции

Лучше всего мыть руки, но когда мыло и вода недоступны, дезинфицирующие средства для рук могут помочь сохранить ваши руки в чистоте.

  1. Проверьте этикетку, сколько использовать, и нанесите продукт на ладонь одной руки.
  2. Потрите руки вместе.
  3. Втирайте средство по всем поверхностям рук и пальцев, пока руки не высохнут, около 20 секунд.
Правильная ручная стирка

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

  1. Смочите руки чистой проточной водой и нанесите мыло.
  2. Потрите руки вместе, хорошо намыливая и вытирая; обязательно потрите тыльную сторону рук, между пальцами и под ногтями.
  3. Продолжайте тереть руки не менее 20 секунд. Это примерно то время, которое нужно, чтобы дважды спеть или спеть «С Днем Рождения» от начала до конца.
  4. Хорошо ополосните руки под проточной водой.
  5. Вытрите руки чистым полотенцем или высушите на воздухе.
Всегда мойте руки до, во время и после приготовления пищи или перед едой. Руки также следует мыть после посещения туалета или смены подгузника, после прикосновения к животному или уборки их отходов, после обращения с мусором, до и после лечения ран, после кашля, чихания или сморкания, а также до и после работы с кем-то, кто болен.

Мыло и моющее средство: в чем разница?

Мыло против моющего средства: в чем разница? И то, и другое поможет вам очистить одежду, но они сделаны по-разному. Мы расскажем вам об основных различиях между мылом и моющим средством, что лучше, и, наконец, о том, как сделать собственное мыло дома.

Итак, если вы ищете способ сделать чистящее средство более естественным и экологически чистым, вы обратились по адресу.

Мыло и моющее средство: в чем разница?

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

Что такое мыло?

Мыло представляет собой комбинацию жира или масла, воды и, наконец, щелочной или основной соли (1) . Он существует примерно с 2800 года до нашей эры.C. и может использоваться для мытья рук, нашего тела и, конечно же, стирки.

Мыло производится двумя способами: холодным или горячим способом.

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

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

Как работает мыло? Удаляет микробы и грязь. У молекул мыла один конец — влаголюбивый, а другой — маслолюбивый. Поэтому, когда вы моете руки, молекулы мыла связываются как с водой, так и с маслом (которые переносят грязь и микробы на наши руки). Когда вы ополаскиваете руки, мыло вместе с водой удаляет микробы.

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

Что такое моющее средство?

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

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

Как и мыло, моющие средства разрушают и удаляют жир, сажу и грязь. Обычно они выпускаются в жидкой, стручковой или порошковой форме, и большинство домашних хозяйств знакомо с их использованием. Фактически, они действуют очень похоже на мыло.

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

Мыло и моющее средство: в чем разница?

Основное различие между мылом и моющим средством — это ингредиенты. Многие бренды маркируют свои моющие средства как «мыло», чтобы казаться более естественными. Итак, лучше всего посмотреть на ингредиенты. Мыло будет производиться из масел, глицерина, щелока, животного жира и ароматических масел среди некоторых других различных биоразлагаемых ингредиентов.

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

Тем не менее, стоит отметить, что существуют биоразлагаемые и экологически чистые моющие средства. Но если посмотреть на ингредиенты, это всего лишь мыло для стирки! Они называются «моющие средства», потому что потребители автоматически связывают слово «моющее средство» с чисткой белья.Так что это хороший маркетинговый прием.

Мы составили удобную таблицу, чтобы выделить основные различия и сходства между мылом и моющим средством.

Характеристики Мыло Моющее средство
Состав Натуральные, биоразлагаемые ингредиенты Смесь натуральных и синтетических химикатов
Форма Жидкость или бар Жидкость, порошок, стручки,
Биоразлагаемый Есть №
Экологичность Есть №
Токсичность Нет Может содержать токсичные ингредиенты
Гипоаллергенный Есть Есть гипоаллергенные варианты
Цена Дороже Дешевле
Происхождение 2800 г.С. Первая мировая война, Германия

Мыло против моющего средства: что лучше?

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

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

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

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

Top Tip

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

Как приготовить мыло в домашних условиях

Если вы хотите приготовить мыло по собственному рецепту, мы вам поможем! Это экологически чистый рецепт стирального порошкового мыла, который легко приготовить и со временем сэкономит много денег.

Что вам нужно

  • 20 унций кокосового масла.
  • 10 унций оливкового масла.
  • Девять унций дистиллированной воды.
  • 4,78 унций 100% чистого щелока.
  • Эфирные масла (по желанию).
  • Резиновые перчатки.
  • Чаша из пластика или керамики.
  • Ручной или палочный блендер.
  • Горшок чугунный или эмалированный.
  • Деревянный или пластиковый шпатель.
  • Формы для мыла или эмалированный противень.
  • Две чашки стиральной соды.
  • Две чашки пищевой соды.
  • Герметичная стеклянная банка.
  • Терка для сыра.

Осторожно

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

Инструкции

Прежде всего, нам нужно сделать кусок мыла. Если хотите, можете купить кусок натурального мыла и пропустить эти шаги. Однако, если вы хотите проявить творческий подход, давайте рассмотрим, как сделать мыло своими руками.

  1. Надев резиновые перчатки, отмерьте все ингредиенты.
  2. Включите кастрюлю и поставьте на слабый огонь.
  3. Добавьте кокосовое масло.
  4. Когда кокосовое масло начнет таять, приготовьте раствор щелочи. Сначала налейте воду в миску. Медленно добавляйте щелок, помешивая деревянной лопаткой.

    Предупреждение

    Никогда не добавляйте воду в щелок, так как это приведет к резкому повышению температуры воды и выделению опасных паров (6) .
  5. Отложите раствор и дайте ему остыть в течение 20 минут.
  6. Если кокосовое масло растаяло, добавьте оливковое масло. Перемешайте.
  7. Если температура масла от 120 до 130 ° F, сначала выключите нагрев. перед тем, как медленно влить раствор щелочи, помешивая.
  8. Установите ручной блендер на низкую скорость и начните перемешивать смесь круговыми движениями.
  9. Делайте это примерно 10 минут или пока смесь не станет густой, как пудинг.
  10. Закройте кастрюлю крышкой и оставьте на 50 минут.
  11. Проверяйте это время от времени. Если он пузырится, хорошенько перемешайте.
  12. Выключите огонь и дайте смеси остыть до 180 ° F.
  13. Добавьте около 30 капель эфирных масел. Мы рекомендуем лаванду и лимон, так как они вместе прекрасно пахнут.
  14. Осторожно разлить смесь по формочкам для мыла. Постучите формами по столешнице, чтобы удалить пузырьки воздуха. (Если у вас нет формы для мыла, вы можете использовать эмалированный противень.)
  15. Дайте ему полностью затвердеть в течение 24 часов.

Из этой смеси у вас должно получиться от семи до 10 кусков мыла. Теперь мы будем использовать их для изготовления стирального порошка.

  1. Добавьте стиральную соду в герметичный контейнер.
  2. Добавьте в емкость пищевую соду.
  3. Натереть на терке один из кусочков домашнего мыла на мелкой терке. Если вы не готовили мыло по рецепту, используйте любой вид натурального мыла и выполните те же действия.
  4. Добавьте тертое мыло в герметичный контейнер.
  5. Закройте емкость крышкой и хорошо встряхните, чтобы ингредиенты перемешались.

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

Как выбрать хорошее моющее средство

Если вы не выбираете домашнее хозяйственное мыло, то как выбрать хорошее моющее средство?

Проверьте ингредиенты

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

На рынке представлено множество экологически чистых моющих средств, но вам нужно знать, что вы ищете. Большинство брендов будут указывать на бутылке, что их моющее средство изготовлено с использованием растительных ингредиентов, но не обязательно указывать все на продукте.

Тип

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

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

Аромат

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

Если вам нравится дополнительный аромат, выберите средство для стирки с запахом эфирных масел. Или добавьте свой во время стирки!

Назначение

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

Какая у вас стиральная машина?

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

Чистая одежда

Что бы вы ни выбрали — мыло или моющее средство — у вас все равно будет чистая одежда.Хотя моющие средства лучше осветляют, отбеливают и удаляют пятна, они не самые экологически чистые.

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

No related posts.

Автор записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *