# REST / SOAP ### Содержание: * [REST](#heading-representational-state-transfer) * [SOAP](#soap) * [Отличия REST и SOAP](#otlichiya-rest-i-soap) * [gRPC](#grpc) В чем разница между REST и SOAP? * **SOAP**: Soap расшифровывается как Simple Object Access Protocol и представляет собой протокол, используемый для получения и отправки данных по протоколу HTTP в виде XML. * **REST**: Это архитектурный стиль, способ разработки веб-сервисов и определения условий работы API. ### Что такое REST? REST, или REpresentational State Transfer, — это архитектурный стиль для предоставления стандартов между компьютерными системами в Интернете, что упрощает взаимодействие систем друг с другом. Системы, совместимые с REST, часто называемые системами RESTful, характеризуются тем, что они не имеют состояния и разделяют задачи клиента и сервера. Мы рассмотрим, что означают эти термины и почему они являются полезными характеристиками для служб в Интернете. Будьте внимательны: если вы ищете карьеру в сфере технологий, вас могут попросить дать определение rest во время собеседования. #### Разделение клиента и сервера В архитектурном стиле REST реализация клиента и реализация сервера могут быть выполнены независимо друг от друга, без ведома друг друга. Это означает, что код на стороне клиента может быть изменен в любое время без ущерба для работы сервера, а код на стороне сервера может быть изменен без ущерба для работы клиента. Пока каждая сторона знает, какой формат сообщений отправлять другой, они могут быть модульными и отдельными. Разделяя проблемы пользовательского интерфейса от проблем хранения данных, мы повышаем гибкость интерфейса на разных платформах и улучшаем масштабируемость за счет упрощения серверных компонентов. Кроме того, разделение позволяет каждому компоненту развиваться независимо. Используя интерфейс REST, разные клиенты обращаются к одним и тем же конечным точкам REST, выполняют одни и те же действия и получают одни и те же ответы. **Примеры запросов и ответов** Допустим, у нас есть приложение, которое позволяет просматривать, создавать, редактировать и удалять клиентов и заказы для небольшого магазина одежды, размещенного на `fashionboutique.com`. Мы могли бы создать HTTP API, который позволяет клиенту выполнять следующие функции: Если бы мы хотели просмотреть всех клиентов, запрос выглядел бы так: ``` GET http://fashionboutique.com/customers Accept: application/json ``` Возможный заголовок ответа будет выглядеть так: ``` Status Code: 200 (OK) Content-type: application/json ``` затем следуют `customers`данные в запрошенном `application/json`формате. Создайте нового клиента, разместив данные: ``` POST http://fashionboutique.com/customers Body: { “customer”: { “name” = “Scylla Buss”, “email” = “scylla.buss@codecademy.org” } } ``` Затем сервер генерирует `id`для этого объекта и возвращает его клиенту с заголовком следующего вида: ``` 201 (CREATED) Content-type: application/json ``` Чтобы просмотреть отдельного клиента, мы *ПОЛУЧАЕМ* его, указав идентификатор этого клиента: ``` GET http://fashionboutique.com/customers/123 Accept: application/json ``` Возможный заголовок ответа будет выглядеть так: ``` Status Code: 200 (OK) Content-type: application/json ``` затем следуют данные по `customer`ресурсу `id`в формате 23 `application/json`. Мы можем обновить этого клиента, добавив новые данные методом *PUT :* ``` PUT http://fashionboutique.com/customers/123 Body: { “customer”: { “name” = “Scylla Buss”, “email” = “scyllabuss1@codecademy.com” } } ``` Возможный заголовок ответа мог бы иметь значение `Status Code: 200 (OK)`, чтобы уведомить клиента о том, что элемент с `id`кодом 123 был изменен. Мы также можем *УДАЛИТЬ* этого клиента, указав его `id`: ``` DELETE http://fashionboutique.com/customers/123 ``` Ответ будет иметь заголовок, содержащий `Status Code: 204 (NO CONTENT)`, уведомляющий клиента о том, что элемент с `id`кодом 123 был удален, и ничего в теле. ### SOAP SOAP (от англ. Simple Object Access Protocol - простой протокол доступа к объектам) - протокол обмена структурированными сообщениями в распределенной вычислительной среде. Первоначально SOAP предназначался в основном для реализации удаленного вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате [**XML**](https://habr.com/ru/post/524288/), а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC. SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP. SOAP является одним из стандартов, на которых базируются технологии веб-служб. [Структура](https://www.w3schools.com/xml/xml_soap.asp) протокола: * Envelope - корневой элемент, который определяет сообщение и пространство имен, использованное в документе; * Header - содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации; * Body - содержит сообщение, которым обмениваются приложения; * Fault - необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений. [Пример SOAP-запроса на сервер интернет-магазина](https://ru.wikipedia.org/wiki/SOAP#:~:text=%D0%BF%D1%80%D0%B8%20%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B5%20%D1%81%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D0%B9.-,%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80,-%5B%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D1%82%D1%8C%20%7C%20%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D1%82%D1%8C%20%D0%BA%D0%BE%D0%B4) [**WSDL**](https://www.w3.org/TR/wsdl.html) - это описательный язык, основанный на языке разметки XML, и именно в wsdl описан веб-сервис, который вам придется тестировать. WSDL включает в себя информацию о местоположении сервиса, часто включает в себя XSD. Именно из WSDL SOAPUI генерирует проверяемые классы. [**XSD**](https://en.wikipedia.org/wiki/XML_Schema_\(W3C\)) - это язык описания структуры XML документа. Его также называют XML Schema. При использовании XML Schema XML парсер может проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных. Если Вы направите в веб-сервис нестандартный запрос, он ответит на это ошибкой. WSDL - это свод правил общения с вашим сервисом, соблюдая которые вы сможете с этим сервисом коммуницировать. Собственно WSDL и XSD подробно описывают что и в каком виде слать на сервер, чтобы получить хороший ответ. Что тестируется в SOAP? Бизнес-логика и то, что схема валидируется сервером (а также, что она принимает на вход параметры правильного формата). Собственно все, что касается схемы, проверяется на этапе разработки, а после, только бизнес-логика (до того момента, пока опять не начнутся изменения в схеме). ### **Отличия REST и SOAP** SOAP и REST нельзя сравнивать напрямую, поскольку первый - это протокол (или, по крайней мере, пытается им быть), а второй - архитектурный стиль. Основное различие между SOAP и REST заключается в степени связи между реализациями клиента и сервера. Клиент SOAP работает как пользовательское настольное приложение, тесно связанное с сервером. Между клиентом и сервером существует жесткое соглашение, и ожидается, что все сломается, если какая-либо из сторон что-то изменит. Вам нужно постоянное обновление после любого изменения, но легче определить, выполняется ли контракт. SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило - в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы - PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен. ### **gRPC** Для тех, кто еще не слышал о gRPC, gRPC - это не зависящий от языка фреймворк для удаленного вызова процедур (RPC, remote procedure calls), разработанный Google, которая серьезно вкладывается в производительность и масштабирование. Он появился довольно давно, но многие (а, может быть, только я) отложили его на второй план из-за затрат на написание IDL и дополнительного кода стабов (stub), который тоже необходимо поддерживать. В то же время REST очень легко реализуется с помощью ASP.NET Core WebAPI. Аналогично использованию JSON для REST, для gRPC используется [Protocol Buffers](https://developers.google.com/protocol-buffers) - не зависящий от языка формат для сериализации структурированных данных. Этим gRPC отличается от REST. Поддержка Protocol Buffers есть для всех основных языков благодаря компилятору protoc, который генерирует необходимый исходный код классов из определений в proto-файле. Еще важный момент состоит в том, что для связи gRPC использует HTTP/2, а это приносит дополнительные преимущества, такие как сжатие HTTP-заголовков и мультиплексирование запросов. | Как тестировать REST API? | | | ------------------------------------ | ------------------------------------------------ | | Тестирование API | | | Swagger. Как пользоваться? | | | Тренажёр для работы с HTTP запросами | | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://qabook.gitbook.io/start/teoriya-testirovaniya/seti-i-arkhitektura/rest-soap.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.