- Главная
- Информатика
- Клиент-серверное взаимодействие HTTP. REST. JSON. SOAP
Содержание
- 2. Клиент-серверное взаимодействие В настоящее время глобальное информационное пространство представлено множеством веб-приложений. Как правило, в их основу
- 3. Клиент-серверное взаимодействие Статическое веб-приложение предполагает применение следующей схемы клиент-серверного взаимодействия. Взаимодействие клиент-серверных веб-систем начинается с инициализации
- 4. Общая схема взаимодействия клиента и интернет-приложения Взаимодействие клиент-серверных веб-систем начинается с инициализации соединения и отправки URL-запроса.
- 5. Протокол прикладного уровня HTTP Протокол – набор соглашений, которые задают единообразный способ передачи сообщений и обработки
- 6. Структура HTTP-запроса Каждое HTTP-сообщение состоит из элементов, которые передаются в указанном порядке: – стартовая строка (обязательный
- 7. HTTP-методы GET, POST, HEAD, PUT, DELETE HTTP метод – регистрозависимая последовательность символов, указывающая на основную операцию
- 8. Структура HTTP-ответа После получения и обработки запроса от клиента, сервер отправляет ответ в виде HTTP-сообщения, которое
- 9. Коды состояния в HTTP протоколе Код состояния – элемент ответа HTTP-сервера, представлен целым числом из трех
- 10. Пример HTTP-ответа и запроса
- 11. Архитектура REST Архитектурный стиль взаимодействия компонентов распределенного приложения REST впервые представил один из авторов HTTP-протокола Рой
- 12. Принципы REST 1. Модель клиент-сервер. Первым принципом, применимым к архитектуре REST, является приведение архитектуры к модели
- 13. RESTful приложения. Формат обмена данными. Обмен данными осуществляется в XML (eXtensible Markup Language), JSON (JavaScript Object
- 14. RESTful приложения. Язык описания веб-приложений Определения сервиса. При интеграции одной системы с другими системами (обслуживаемыми несколькими
- 15. RESTful приложения. Использование HTTP-методов Архитектура REST полностью построена на основе протокола HTTP, а также устанавливает однозначное
- 16. RESTful приложения. Предоставление URI Согласно архитектуре REST, URI рассматривается как самодокументирующийся интерфейс, не требующий пояснения или
- 17. RESTful приложения. Формат обмена данными JSON JSON (JavaScript Object Notation) – текстовый формат обмена данными, основанный
- 18. RESTful приложения. Представление значений в нотации JSON Строка – заданная последовательность, заключенная в двойные кавычки. "Иван"
- 19. RESTful приложения. Представление вложенных объектов JSON Использование вложенности в JSON-формате позволяет обрабатывать сложные данные. Например, в
- 20. SOAP SOAP (Simple Object Access Protocol) – протокол обмена структурированными сообщениями в распределенной среде. Протокол используется
- 21. Структура-сообщения SOAP SOAP-сообщение представляет собой XML-документ. Сообщение состоит из трех основных элементов: конверт (SOAP Envelope), заголовок
- 22. Пример SOAP-запроса и SOAP-ответа Данный пример демонстрирует использование SOAP-сообщения, отправляемое на сторону сервера с помощью метода
- 24. Скачать презентацию
Слайд 2Клиент-серверное взаимодействие
В настоящее время глобальное информационное пространство представлено множеством веб-приложений. Как правило,
Клиент-серверное взаимодействие
В настоящее время глобальное информационное пространство представлено множеством веб-приложений. Как правило,
1. Представление. Это интерфейсный (обычно графический) компонент комплекса, предоставляемый конечному пользователю. Этот уровень не должен иметь прямых связей с базой данных (по требованиям безопасности и масштабируемости), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надёжности). На этот уровень обычно выносится только простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции с данными (сортировка, группировка, подсчёт значений), уже загруженными на терминал.
2. Веб-сервер, обеспечивающий обработку запросов клиентов и формирование ответов на основе исполнения сценариев и запросов к серверным базам данных или иным структурированным или неструктурированным источникам.
3. Хранение данных. Службы хранения данных обеспечиваются различными структурированными и неструктурированными информационными хранилищами, вспомогательными инструментами, которые обеспечивают доступ к необходимым данным из различных областей приложения
Существует широкий выбор компонентов и технологий, которые могут быть частью архитектуры веб-приложений. В результате построение архитектурной модели сводится к выбору основных функциональных компонентов системы, архитектурных решений на каждом из уровней проектируемого веб-приложения, где центральное место занимают процессы интерпретации.
Слайд 3Клиент-серверное взаимодействие
Статическое веб-приложение предполагает применение следующей схемы клиент-серверного взаимодействия. Взаимодействие клиент-серверных веб-систем
Клиент-серверное взаимодействие
Статическое веб-приложение предполагает применение следующей схемы клиент-серверного взаимодействия. Взаимодействие клиент-серверных веб-систем
Динамическое веб-приложение реализует следующую модель поведения. Клиентская сторона обращается к серверному сценарию, который, получив соответствующий запрос, выполняет предусмотренные действия для динамического формирования страницы. Серверные сценарии по мере необходимости выполняют выборку данных из соответствующего источника и представляют динамически сгенерированное содержание клиенту.
Слайд 4Общая схема взаимодействия клиента и интернет-приложения
Взаимодействие клиент-серверных веб-систем начинается с инициализации соединения и
Общая схема взаимодействия клиента и интернет-приложения
Взаимодействие клиент-серверных веб-систем начинается с инициализации соединения и
В случае если клиентский запрос принимается на определенную статическую страницу, то серверное приложение, самостоятельно обслужив запрос, отправляет HTML-содержимое запрашиваемой страницы.
Если клиентская сторона обращается к серверному сценарию, выполняются предусмотренные действия для динамического формирования страницы.
Серверные сценарии по мере необходимости выполняют выборку данных из соответствующего источника и представляют динамически сгенерированное содержание клиенту.
В простейшем случае это HTML-код, в соответствии с которым браузер формирует изображение. В более сложном случае ответ включает информационные объекты, предназначенные для дальнейшей интерпретации на стороне клиента.
Слайд 5Протокол прикладного уровня HTTP
Протокол – набор соглашений, которые задают единообразный способ передачи сообщений
Протокол прикладного уровня HTTP
Протокол – набор соглашений, которые задают единообразный способ передачи сообщений
HTTP – протокол прикладного уровня передачи данных, изначально – в виде гипертекстовых документов в формате HTML. Ресурс HTTP-запроса – различные объекты: файлы, документы, фото и т. п. URI – унифицированный) идентификатор ресурса (/department/). URL – это URI, который, помимо идентификации ресурса, cодержит и информацию о местонахождении ресурса (http:://localhost:8080/department/).
Характеристики HTTP протокола.
Основан на клиент-серверной архитектуре (клиент – программа (например, браузер), который устанавливает соединение с сервером для отправки одного или нескольких HTTP-запросов, сервер – программа, которая обрабатывает запрос и отправляет HTTP-ответ).
Каждый ресурс идентифицируется с помощью унифицированного идентификатора ресурса.
HTTP не привязан к конкретному типу данных. Можно передавать любой тип данных при условии, что клиент и сервер способны обрабатывать выбранный тип данных. Сервер и клиент должны определяют тип контента с помощью MIME(Multipurpose Internet Mail Extensions - многоцелевые расширения интернет-почты). MIME-тип – стандарт, который описывает формат документа, файла или набора байтов. Структура MIME-типа: тип/подтип (например, application/json).
Протокол HTTP синхронный, но позволяет клиенту отправлять несколько запросов подряд, не дожидаясь ответа сервера, при условии, что сервер отправит ответы на запросы в том порядке, как они приходили.
Взаимодействует только через соединение. Клиент и сервер могут взаимодействовать друг с другом только с помощью запроса, ни клиент, ни сервер не могут получить информацию за пределами запроса.
Не зависит от соединения. Для отправки запроса клиент устанавливает соединение с сервером и отсоединяется после отправки запроса. Сервер, в свою очередь, обрабатывает запрос и устанавливает соединение с клиентом для отправки ответа и отсоединяется после нее. HTTP/1.0 использует соединение для каждого цикла “запрос/ответ”. HTTP/1.1 может использовать один или несколько циклов “запрос-ответ” внутри одного соединения.
Слайд 6Структура HTTP-запроса
Каждое HTTP-сообщение состоит из элементов, которые передаются в указанном порядке:
Структура HTTP-запроса
Каждое HTTP-сообщение состоит из элементов, которые передаются в указанном порядке:
– заголовки (опциональный элемент);
– пустая строка (обязательный элемент, которая определят конец полей элемента header);
– тело сообщения (опциональный элемент).
Стартовая строка (starting line) или строка состояния – определяет метод передачи, версию протокола HTTP, а также URL, к которому должен выполняется запрос. Стартовая строка запроса имеет следующий формат: метод (пробел) URI запроса (пробел) версия-HTTP (следующая строка).
GET /students.html HTTP/1.1 (cтрока-запрос, сделанный клиентом)
Заголовки (headers) – характеризуют тело сообщения, параметры передачи и различную служебную информацию. Порядок HTTP заголовков не имеет значения. Однако желателен следующий порядок заголовков: общие заголовки, заголовки запроса (или заголовки ответа) и заголовки объекта.
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36
Last-Modified: Sat, 23 Jan 2020 21:16:42 GMT
Authorization: sso_1.0_b390cde1-532e-4387-bcbd-f9e0a4aaac13
Content-Type: application/json
Content-Length: 20
Тело сообщения (message body) содержит объект, связанный с запросом, либо с ответом. Тело сообщения содержит данные HTTP запроса (тип данных и т.д.), а HTTP ответ содержит данные, полученные от сервера (файлы, изображения и т.д.).
{caption_like: "Test"}
Слайд 7HTTP-методы GET, POST, HEAD, PUT, DELETE
HTTP метод – регистрозависимая последовательность символов, указывающая
HTTP-методы GET, POST, HEAD, PUT, DELETE
HTTP метод – регистрозависимая последовательность символов, указывающая
GET – метод генерирования данных, используемый клиентским приложением для получения информации от сервера по заданному URL. Запросы клиентов, использующие метод GET должны получать только данные и не должны оказывать влияния на данные. Например, получение HTML-файла, который содержит информацию о студентах кафедры.
POST – необходим для создания нового ресурса. Например, отправить данные на сторону сервера из HTML-формы, а также добавить данные в базу данных.
HEAD – используется для получения метаинформации об объекте без отправки тела HTTP-сообщения. В качестве ответа сервер отправляет только заголовки и статусную строку без тела HTTP-сообщения. Например, тестирование HTTP-соединения, а также достижимости узлов/ресурсов (тестирование HTTP методом HEAD осуществляется быстрее, т.к. не предполагает отправку содержимого). Например, для получения информации о дате обновления ресурса (затем использовать GET для получения его содержания).
PUT – обеспечивает обновление существующего ресурса (или создание нового). Например, обновление информации о конкретном студенте.
DELETE – запрашивает сервер об удалении ресурса. Действие метода DELETE может быть отменено вмешательством администратора сервера или программным кодом. Использование данного метода гарантирует завершение операции удаления, даже если код состояния, возвращенный первоначальным сервером указывает на то, что действие было завершено успешно.
Слайд 8Структура HTTP-ответа
После получения и обработки запроса от клиента, сервер отправляет ответ в
Структура HTTP-ответа
После получения и обработки запроса от клиента, сервер отправляет ответ в
– строка статуса (обязательный элемент);
– заголовок (опциональный элемент);
– пустая строка (указывает на окончание заголовка – обязательный элемент);
– тело сообщения (опциональный элемент).
Стартовая строка ответа сервера имеет следующий формат:
Версия-HTTP (пробел) Код-статуса (пробел) Текстовое-сообщение
HTTP/1.1 200 OK (строка-Статуса, отправленная сервером)
Код статуса (состояния) – это число, определяющие тип ответа, а также конкретную ошибку.
403 Forbidden //доступ запрещен
Заголовок ответа – позволяет серверу передать дополнительную информацию об ответе, которая не может быть помещена в строке состояния:
Content-Type: application/json; charset=UTF-8
Date: Tue, 26 Jan 2021 16:47:30 GMT
Слайд 9Коды состояния в HTTP протоколе
Код состояния – элемент ответа HTTP-сервера, представлен целым числом
Коды состояния в HTTP протоколе
Код состояния – элемент ответа HTTP-сервера, представлен целым числом
Описание HTTP кодов состояния.
1xx: информационные коды состояния. В этот класс выделены коды, информирующие о процессе передачи. Например, 100 Continue – сервер удовлетворен начальными сведениями о запросе, клиент может продолжать отправлять заголовки; 102 Processing – запрос принят, но на его обработку необходимо длительное время.
2xx: успешные коды состояния. Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может также отправить заголовки и тело сообщения. Например:
200 OK – успешный запрос. Если клиентом были запрошены данные, то они находятся в заголовке и/или теле сообщения; 201 Created – в результате успешного выполнения запроса был создан новый ресурс.
3xx: коды перенаправления. Коды данного класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Например:
301 Moved Permanently – запрошенный документ был перенесен на новый URI, указанный в поле Location заголовка;
300 Multiple Choices – по указанному URI существует несколько вариантов предоставления ресурса по типу MIME (по языку или по другим характеристикам). Сервер передает с сообщением список альтернатив, предоставляя возможность сделать клиенту выбор.
4xx: коды ошибок клиента. Предназначены для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя. Например:
400 Bad Request – в запросе клиента обнаружена синтаксическая ошибка;
401 Unauthorized – для доступа к запрашиваемому ресурсу требуется аутентификация;
404 Not Found – ошибка в написании адреса страницы.
5xx: коды ошибок сервера. Выделены для случаев необработанных исключений при выполнении на стороне сервера. Для всех запросов (кроме HEAD-метода) сервер должен включать в тело сообщения отображение для пользователя. Например: 502 Bad Gateway – сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера;
500 Internal Server Error – любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса.
Слайд 10Пример HTTP-ответа и запроса
Пример HTTP-ответа и запроса
Слайд 11Архитектура REST
Архитектурный стиль взаимодействия компонентов распределенного приложения REST впервые представил один из авторов
Архитектура REST
Архитектурный стиль взаимодействия компонентов распределенного приложения REST впервые представил один из авторов
REST (Representational State Transfer) – архитектурный стиль взаимодействия компонентов распределенного приложения. Представляет собой согласованный набор ограничений, учитываемых при проектировании распределенной системы. Накладываемые ограничения определяют работу сервера в том, как он может обрабатывать и отвечать на запросы клиентов. Действуя в рамках этих ограничений, система приобретает свойства производительности, масштабируемости, простоты, способности к изменениям, переносимости, отслеживаемости и надежности.
REST-ресурс – абстракция некоторой сущности, которой можно дать имя (как классы в Java): пользователь, документ, задача, список задач, отчет, заказ, видео, анимация, PDF-файл.
URL-ресурса – последовательность символов, которая не подлежит изменению при изменении состояния ресурса, идентифицирующая абстрактный или физический ресурс. Идентификатором в REST является URI. Пример: POST/users (создать пользователя), DELETE /users/1 (удалить пользователя), GET /users (вернуть (получить) всех пользователей), GET /users/1 (Получить одного пользователя).
RESTful система – система, построенная с учетом REST (то есть не нарушающая накладываемых архитектурой ограничений).
Слайд 12Принципы REST
1. Модель клиент-сервер. Первым принципом, применимым к архитектуре REST, является приведение
Принципы REST
1. Модель клиент-сервер. Первым принципом, применимым к архитектуре REST, является приведение
2. Независимость от состояния (stateless protocol или «протокол без сохранения состояния). Протокол взаимодействия между клиентом и сервером требует соблюдения следующего условия: в период между запросами клиента никакая информация о состоянии клиента не хранится на стороне сервера. Все запросы от клиента должны быть составлены так, чтобы сторона сервера получила всю необходимую информацию для выполнения запроса. Состояние сессии при этом сохраняется на стороне клиента. Информация о состоянии сессии может быть передана сервером какому-либо другому сервису (например, в службу базы данных) для поддержания устойчивого состояния, например, на период установления аутентификации. Клиент инициирует отправку запросов, когда он готов (возникает необходимость) перейти в новое состояние.
3. Кэшируемая архитектура (Cacheable). Клиенты, а также промежуточные узлы могут выполнять кэширование ответов сервера. Ответы сервера, в свою очередь, должны иметь явное или неявное обозначение как кэшируемые (на определенный период) или некэшируемые с целью предотвращения получения клиентами устаревших или неверных данных в ответ на последующие запросы. Правильное использование кэширования способно полностью или частично устранить некоторые клиент-серверные взаимодействия, ещё больше повышая производительность и расширяемость системы.
4. Единый унифицированный программный интерфейс. Наличие унифицированного интерфейса является фундаментальным требованием дизайна REST-приложений. Унифицированные интерфейсы позволяют каждому из сервисов развиваться независимо от функциональности системы.
5. Многоуровневая архитектура (Layered System). Предполагается выделение в системе иерархии слоев, согласно следующему условию. Каждому компоненту REST-приложения доступны только компоненты непосредственно следующего слоя. Например, при вызове службы PayPal, данной платежной системой будет выполнен вызов службы поддержки кредитных Visa.
6. Представление данных. В качестве представления данных объекта передаются данные в формате JSON, XML или в обоих форматах.
Слайд 13RESTful приложения. Формат обмена данными.
Обмен данными осуществляется в XML (eXtensible Markup
RESTful приложения. Формат обмена данными.
Обмен данными осуществляется в XML (eXtensible Markup
Слайд 14RESTful приложения. Язык описания веб-приложений
Определения сервиса. При интеграции одной системы с другими
RESTful приложения. Язык описания веб-приложений
Определения сервиса. При интеграции одной системы с другими
WADL (Web Application Definition Language) – машиночитаемое XML-описание приложений на основе HTTP. Описывается с помощью набора элементов ресурса.
Элемент запроса указывает как представлять ввод, какие типы требуются и какие требуются конкретные заголовки HTTP.
Ответ описывает представление ответа сервиса, а также любую информацию о неисправности.
WADL является REST-эквивалентом SOAP «Web Services Description Language (WSDL), который также может быть использован для описания REST-приложений.
Слайд 15RESTful приложения. Использование HTTP-методов
Архитектура REST полностью построена на основе протокола HTTP, а
RESTful приложения. Использование HTTP-методов
Архитектура REST полностью построена на основе протокола HTTP, а
Например, для получения информации о конкретном студенте (по идентификатору, по значению поля name) в формате json необходимо выполнить следующие запросы:
GET /students/5
Accept : application/json
GET /firt/acs/student?name=Иван
Следующий запрос обеспечивает создание нового студента (с указанием наименования идентификатора факультета и наименования идентификатора кафедры) со следующими полями: имя – Иван, фамилия – Иванов, наименование кафедры АСУ:
POST /firt/acs/student {
"name" : "Иван",
"surname" : "Иванов",
}
Редактирование фамилии студента осуществляется следующим образом:
PUT /firt/acs/student/5 {
"surname" : "Петров",
}
Удаление информации о студенте осуществляется HTTP-методом DELETE :
DELETE /firt/acs/student/5
Слайд 16RESTful приложения. Предоставление URI
Согласно архитектуре REST, URI рассматривается как самодокументирующийся интерфейс, не
RESTful приложения. Предоставление URI
Согласно архитектуре REST, URI рассматривается как самодокументирующийся интерфейс, не
Рекомендации на представление структуры URI для RESTful-приложений:
– URI должны быть статичными и не подлежать изменению при модификации ресурсов или реализации сервиса;
– скрывать расширения файлов серверных сценариев (.jsp, .php, .asp) для выполнения портирования приложений на другую технологию без изменения URI;
– содержать только строчные буквы;
– заменять пробелы дефисами или знаками подчеркивания;
– максимально избегать использования строк запросов.
Например, для получения списка студентов необходим URL: GET localhost:8080/students
Для получения информации о конкретном студенте URI – GET /students/1
Для получения информации о факультетах – GET localhost:8080/faculty
Для удаления информации о конкретном студенте – DELETE localhost:8080/students/1
Для добавления информации факультете – POST localhost:8080/faculty
{"code": "ENF",
"dean": "Декан ЕНФ",
"name": "ЕНФ"}
Слайд 17RESTful приложения. Формат обмена данными JSON
JSON (JavaScript Object Notation) – текстовый формат
RESTful приложения. Формат обмена данными JSON
JSON (JavaScript Object Notation) – текстовый формат
JSON-текст представляет собой (в закодированном виде) одну из двух структур:
1. Набор пар ключ: значение:
– значением может быть любая допустимая форма представления;
– ключом – только строка, регистрозависимость строки определяется документацией программного обеспечения и не регулируется стандартом;
– повторяющиеся имена ключей допустимы (не рекомендуются стандартом), а обработка также происходит согласно документации программного обеспечения программного обеспечения. Например, учет только первого ключа, учет только последнего ключа, генерирование ошибки.
2. Упорядоченный набор значений, который во многих языках программирования реализован как массив, вектор, список или последовательность.
Слайд 18RESTful приложения. Представление значений в нотации JSON
Строка – заданная последовательность, заключенная в
RESTful приложения. Представление значений в нотации JSON
Строка – заданная последовательность, заключенная в
Объект – неупорядоченный набор пар ключ/значение. Объект начинается с открывающей фигурной скобки и заканчивается закрывающейся. Пример объекта students, где students – ключ, а всё, что находится внутри фигурных скобок – объект:
{"students" : {"firstName":"Иван", "lastName":"Иванов"}}
Число – в JSON должно быть целым или с плавающей запятой.
{"content": {"dateBegin": "2020-10-26",
"name": "Тестовая услуга",
"repeatPeriod": 30, "amount": 450.40 … }}
Булевый тип также может быть использован в качестве значения:
{"content": {"name": "Тестовая услуга",
"isClientSupport": true, "moment": false}}
null – показывает отсутствие информации:
{"content": {"name": "Тестовая услуга",
"statusComment": null, "subprocess": null}}
Массив – упорядоченная коллекция значений. Пример массива, состоящего из трех объектов:
{"content": {"name": "Тестовая услуга для формирования",
"subprocess": [ {"id": 1350, "dateBegin": "2020-10-26", "finish": true}, {"id": 22, "dateBegin": "2020-12-26", "finish": true}, {"id": 2, "dateBegin": "2021-04-01", "finish": false} ]} }
Слайд 19RESTful приложения. Представление вложенных объектов JSON
Использование вложенности в JSON-формате позволяет обрабатывать сложные
RESTful приложения. Представление вложенных объектов JSON
Использование вложенности в JSON-формате позволяет обрабатывать сложные
{"content": [
{"name": "Тестовая услуга 1", "status": { "id": 4, "caption": "Действующая" }},
{ "name": "Тестовая услуга 2", "status": { "id": 2, "caption": "Черновик" }},
{"name": "Тестовая услуга 3", "status": {
"id": 3, "caption": "На согласовании" }},
{"name": "Тестовая услуга 4", "status": { "id": 5, "caption": "Завершено" }}] }
Слайд 20SOAP
SOAP (Simple Object Access Protocol) – протокол обмена структурированными сообщениями в распределенной
SOAP
SOAP (Simple Object Access Protocol) – протокол обмена структурированными сообщениями в распределенной
Характеристики SOAP.
– протокол SOAP позволяет приложениям взаимодействовать между собой, используя SOAP-сообщения (XML-документы);
– SOAP совместим с любой объектной моделью, поскольку включает функции и методы, которые необходимы для формирования коммуникационной инфраструктуры;
– является независимым от платформы и конкретных приложений, а для его реализации может быть использован любой язык программирования;
– поддерживает практически любой транспортный протокол;
– поддерживает любые методы кодирования данных, которые позволяют приложениям, основанным на SOAP, отправлять в сообщениях SOAP информацию практически любого типа (например, изображения, объекты, документы и т.д.);
– вызов привязывается к HTTP-запросу, так что сообщение отправляется через HTTP-запрос POST;
– сообщение-ответ SOAP представляет собой документ HTTP-ответа, который содержит результаты вызова метода (например, возвращаемые значения, сообщения об ошибках и т.д.);
– для предоставления используется WSDL (Web Services Description Language);
– SOAP для передачи сообщений увеличивает их объем и снижает скорость обработки.
Слайд 21Структура-сообщения SOAP
SOAP-сообщение представляет собой XML-документ. Сообщение состоит из трех основных элементов: конверт
Структура-сообщения SOAP
SOAP-сообщение представляет собой XML-документ. Сообщение состоит из трех основных элементов: конверт
Envelope – корневой элемент (обязательный), который определяет сообщение (включает дочерний элемент Body) и пространство имен (определяется с помощью ENV и элемента Enveloper) документе. Необходимость данного элемента заключается в следующем. Клиентская сторона определяет, что сообщение получено полностью и готово к обработке.
Header – первый для обработки элемент (необязательный), который находится внутри элемента envelope, содержащий атрибуты сообщения. Элементов header в файле может быть несколько.
Body – обязательный элемент, содержащий XML-данные для отправки конечному пользователю SOAP-сообщения.
Fault — необязательный элемент, возвращающий информацию об ошибках, которые произошли при обработке сообщений. Если при обработке SOAP-сообщения SOAP-сервер сгенерирует ошибку, то дальнейшая обработка будет остановлена, а на сторону клиента будет отправлено SOAP-сообщение, содержащее один элемент Fault с сообщением об ошибке
Слайд 22Пример SOAP-запроса и SOAP-ответа
Данный пример демонстрирует использование SOAP-сообщения, отправляемое на сторону сервера
Пример SOAP-запроса и SOAP-ответа
Данный пример демонстрирует использование SOAP-сообщения, отправляемое на сторону сервера
Пример ответа представляет также XML-файл, который содержит ответ обработчика. Обработчик getProduct возвращает данные на основании параметра.